предисловие

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

Что такое парадигма?

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

НижеВикипедияОбъяснение в:

Database normalization is the process of structuring a relational database in accordance with a series of so-called normal forms in order to reduce data redundancy and improve data integrity. It was first proposed by Edgar F. Codd as part of his relational model.

Подводя итог в одном предложении: парадигмы проектирования баз данных могут помочь нам уменьшить избыточность данных при одновременном повышении целостности данных.

Предварительное знание

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

Сначала мы определяем таблицу и добавляем некоторые данные, эта таблица 1 (таблица выбора курса) помогает нам понять эти концепции:

код

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

код кандидата

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

Сформулируем это более строго: предположим, что К — это атрибут или группа атрибутов в некоторой таблице, если все атрибуты, кроме К,полная функциональная зависимость(будет введено позже) в K, то мы называем K ключом-кандидатом.

В соответствии с примером в приведенной выше таблице мы можем нарисовать код кандидата:

• (номер учащегося, название класса)

Мастер код

Обычно мы выбираем код из кода-кандидата какМастер код, который мы обычно называем первичным ключом.

функциональные зависимости

Математическое объяснение:, введите X, вы можете получить определенный Y. Что-то вроде чистой функции.

В соответствии с таблицей, когда определен атрибут (группа атрибутов) X, должно быть определено значение атрибута Y, которое можно назвать функцией Y, зависящей от X, записанной X -> Y​.

Упоминается как:

Например, следующие отношениясуществуетФункциональные зависимости:

• (номер ученика) -> (имя)
• (номер ученика, название класса) -> (оценка)
• (Название отдела) -> (Председатель отдела)

Однако следующие соотношенияне существуетФункциональные зависимости:

• (имя) -> (номер учащегося), т.к. могут быть повторяющиеся имена, определить номер учащегося только по имени невозможно.
• (номер студента) -> (оценка), потому что номер студента имеет несколько предметов, каждый предмет имеет балл, и балл не может быть определен только номером студента.
• ...

полная функциональная зависимость

В таблице, если есть X -> Y, то для любого правильного подмножества (X') под X, X' -> Y не выполняется, тогда мы говорим, что Y завершает функциональную зависимость от X.

Обозначается как: X -> F Y

С точки зрения непрофессионала, значение должно однозначно определяться всеми атрибутами в коде. Например:

• (номер ученика) -> F (имя)
• (номер ученика, название класса) -> F (оценка)

частичные функциональные зависимости

В таблице, если есть X -> Y, но Y не полностью зависит от X. Существует некоторое подмножество X' множества X и выполняется X' -> Y, тогда мы говорим, что Y частично функционально зависит от X.

Обозначается как: X -> P Y

С точки зрения непрофессионала, для однозначного определения значения необходимы только некоторые атрибуты в коде. Например:

• (номер ученика, имя класса) -> (имя), нужно только однозначно определить имя по номеру ученика в коде.

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

зависимости передаточной функции

Если функция Z зависит от Y, функция Y зависит от X, а X не является функциональной от Y, то мы говорим, что передаточная функция Z зависит от X.

Обозначается как: X -> T Z

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

Атрибуты

Атрибут — это каждый столбец, который мы определяем в таблице.

главный атрибут

Все атрибуты (каждый столбец) в коде называются основными атрибутами.

неосновной атрибут

Атрибуты, отличные от первичных атрибутов, называются непервичными атрибутами.

Парадигма

С приведенными выше концепциями мы теперь можем формально говорить о парадигмах. Существует множество парадигм проектирования баз данных: 1NF, 2NF, 3NF, BCNF, 4NF, 5NF, 6NF и так далее.

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

Обычно в моем дизайне высшая также следует за BCNF, обычно 3NF.

1NF

1NF, также известная как первая нормальная форма. Эта парадигма может быть удовлетворена до тех пор, пока данные в каждом столбце неразделимы, а таблицы, созданные реляционными базами данных, поддерживают эту парадигму по умолчанию. Но некоторые разработчики поступают наоборот, например, следующий дизайн Таблицы 2:

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

в заключении:Атрибуты неделимы.

2NF

1NF — это только самое основное требование для проектирования базы данных, но в данных будет много избыточности, а также будут исключения удаления, исключения вставки и исключения обновления. Мы смотрим на Таблицу 1 в начале.

В этой таблице есть следующие проблемы:

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

Для решения вышеуказанных проблем мы введем более высокий уровень второй нормальной формы (2НФ).

Какие улучшения делает 2NF по сравнению с 1NF?

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

Проанализируем Таблицу 1:

Код: (номер учащегося, название класса)

Основной атрибут: (номер студента, название курса)

Неосновные атрибуты: (имя, название кафедры, заведующий кафедрой, класс, название курса, оценка)

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

1. найти всекод (код кандидата).
2. По коду, полученному на первом шаге, найти всеглавный атрибут.
3. Все остальные атрибуты, кроме основного атрибута,неосновной атрибут.
4. Определить, есть ли неосновной атрибутчастичные функциональные зависимостив коде.

Мы следуем описанным выше шагам, чтобы убедиться, что таблица 1 соответствует 2NF.

первый шаг

Найдите все коды-кандидаты в таблице.

Как найти коды кандидатов? Только используйте перестановки и комбинации, чтобы узнать.

• Сначала посмотрите на каждый атрибут, если атрибут определен, может ли запись быть однозначно определена.
• Посмотрите на группу атрибутов для каждой комбинации двух атрибутов и, если группа атрибутов определена, можно ли однозначно определить запись.
• ...

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

Если мы должны сделать собственное суждение, мы можем сделать вывод, что в соответствии с характеристиками кода-кандидата с полной функциональной зависимостью: если А является кодом, то любая группа атрибутов, объединенная с А, не соответствует требованиям кода, например: (А, В) (А, В, С) и так далее.

Согласно приведенному выше объяснению, на этом шаге мы можем получить коды-кандидаты в таблице 1:(номер учащегося, название класса)

второй шаг

Найдите все основные атрибуты по коду.

Этот шаг относительно прост, код, найденный на первом шаге, состоит только из (номер ученика, имя класса). Таким образом, основным атрибутом является только (номер ученика, название класса).

третий шаг

Все остальные атрибуты, кроме основного атрибута, являются неосновными атрибутами.

Таким образом, неосновными атрибутами являются (имя, название кафедры, заведующий кафедрой, класс, оценка).

четвертый шаг

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

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

• Для (номер учащегося, имя класса) -> (имя), существует (номер учащегося) -> (имя), есть неосновной атрибутИмяНекоторые функции зависят от кода.

• Для (номер учащегося, название курса) -> (название кафедры), существует (номер учащегося) -> (название кафедры) существует неосновной атрибутНазвание отделаНекоторые функции зависят от кода.

• ...

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

В таком случае, что нам следует улучшить, чтобы таблица 1 соответствовала требованиям 2NF? Конечно, таблица разбита, и эти частичные функциональные зависимости устранены.Есть более формальное название:Разложение шаблона.

Мы можем разделить таблицу выбора курсов на две таблицы: таблицу выбора курсов и таблицу студентов.

Давайте теперь посмотрим на выборную таблицу. На данный момент у него есть только один код:(номер учащегося, название класса), есть только один неосновной атрибут:Дробная часть. Они уже не частично функционально зависимы, а полностью функционально зависимы. В таблице выбора курса нет частичной функциональной зависимости, поэтому таблица выбора курса находится во второй нормальной форме (2NF).

Давайте теперь посмотрим, соответствует ли таблица учеников 2NF.

Выполните четыре шага выше:

1. Код: (номер студента)
2. Основной атрибут: номер студента
3. Неосновные атрибуты: (имя, название кафедры, заведующий кафедрой, класс)
4. Поскольку в коде имеется только одно свойство, частичные функциональные зависимости невозможны.

Таким образом, таблица учеников также находится во 2NF.

в заключении:На основе 1НФ путем разбиения таблицы устраняется частичная функциональная зависимость кода непервичной пары атрибутов в таблице.

3NF

Мы разделили Таблицу 1 на две таблицы через 2NF: таблицу выбора курса и таблицу студентов. Но есть еще некоторые проблемы, такие как:

• Когда студент в таблице студентов удаляется, информация об отделе также будет удалена. Если все содержимое таблицы студентов будет удалено, вся информация об отделе не будет существовать.
• Когда создается новая кафедра, но в ней нет студентов, информация о кафедре не может быть добавлена.

Мы уже знаем из предыдущего раздела, что и таблица выбора курсов, и таблица студентов соответствуют 2NF, но в таблице студентов все еще есть некоторые проблемы. Поэтому таблица, соответствующая 2NF, может не обязательно соответствовать нашим требованиям. На данный момент мы будем использовать 3NF.

Пока существует зависимость передаточной функции неосновного атрибута от кода в таблице, требования 3NF не выполняются. Следовательно, для 3NF он основан на 2NF для устранения неосновного кода пары атрибутов.зависимости передаточной функции.

Проанализируем функциональные зависимости в следующей таблице ученика:

1. Найдите код в таблице учеников: (номер ученика)
2. Основной атрибут: номер студента
3. Неосновные атрибуты: (номер учащегося, название кафедры, заведующая кафедрой, баллы)
4. Существует зависимость передаточной функции между номером студента и заведующим кафедрой

Как видно из рисунка, пока мы определяем номер студента, мы можем определить название кафедры, а как только название кафедры определено, мы можем определить заведующую кафедрой. Поэтому, когда количество студентов определено, мы можем определить и заведующего кафедрой. Это передаточная функциональная зависимость.

Метод устранения зависимостей передаточной функции также осуществляется путем разделения таблицы.Мы разделяем таблицу студентов на две таблицы: таблицу студентов и таблицу кафедры.

После разделения таблица студентов устраняет транзитивную зависимость функции, поэтому в это время таблица студентов соответствует 3NF, а таблица отделов также соответствует 3NF.

в заключении:На основе 2НФ устранена зависимость передаточной функции непервичных атрибутов от кодов в таблице.

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

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

BCNF

Мы узнали об 1NF, 2NF, 3NF и решили проблему с помощью этих трех парадигм, так почему же до сих пор существует BCNF? Какую проблему решает эта парадигма? Давайте посмотрим на BCNF с этими двумя вопросами.

Прежде всего, следует отметить, что все три приведенные выше таблицы после разделения соответствуют BCNF. Увидев это, малыш, у тебя много вопросительных знаков?

Не волнуйтесь, давайте сначала посмотрим на определение BCNF: не существуетглавный атрибутДля частичных функциональных зависимостей и переноса функциональных зависимостей кода он соответствует BCNF.

Примечание: здесь написаноглавный атрибут, а предыдущие 2NF и 3NF обанеосновной атрибутЧастичные функциональные зависимости и перенос функциональных зависимостей на код. Важно отметить это различие.

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

Например следующая ситуация:

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

Давайте проанализируем эту таблицу:

• Код: (имя склада, название товара), (admin, название товара)
• Основные атрибуты: название склада, наименование товара, администратор
• Неосновной атрибут: Количество

Непервичный атрибут имеет только «количество», а непервичный атрибут не имеет частичных функциональных зависимостей и передаточных функциональных зависимостей для обоих кодов, поэтому эта таблица находится в 3NF. Но эта таблица не совместима с BCNF.

Потому что есть частичная функциональная зависимость основного свойства от кода:

• (имя склада, имя товара) -> администратор, если имя склада определено, можно определить администратора, поэтому некоторые функции администратора зависят от имени склада.
• (Администратор, название товара) -> название склада, как указано выше.

Затем нам нужно разделить таблицу, чтобы таблица элементов соответствовала BCNF. Разделите таблицу на две таблицы: таблицу склада и таблицу товаров.

Мы можем посмотреть, какие проблемы решаются после разделения:

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

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

в заключении:На основе 3NF устраняются частичные функциональные зависимости и передаточные функциональные зависимости пар основных атрибутов кодов.

Суммировать

Из приведенного выше анализа видно, что, хотя мы не знаем этих парадигм, когда обычно проектируем таблицы, большинство из них следуют этим парадигмам, по крайней мере, 2NF. Потому что, пока мы строим таблицу для каждого независимого человека, большинство из них могут соответствовать 3NF.

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

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

Ссылаться на

1. Как понять общие парадигмы проектирования реляционных баз данных?
2. нормализация базы данных
3. Database normalization