Руководство По Проектированию Реляционных Баз Данных (10-13 Часть Из 15) [Перевод]

Продолжение.

Предыдущие части: 1-3 , 4-6 , 7-9

10. Нормализация базы данных

Они собраны в 5 групп, которые называются нормальные формы .

Первая нормальная форма представляет собой самый низкий уровень нормализации базы данных.

Пятый уровень представляет собой высший уровень нормализации.

Нормальные формы – это рекомендации по проектированию базы данных.

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

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

• В нормализованной структуре базы данных вы можете выполнять сложный выбор данных с помощью относительно простых запросов SQL.
• Целостность данных .

  Нормализованная база данных позволяет безопасно хранить данные.

• Нормализация предотвращает избыточность хранимых данных .

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

  Из этого правила есть исключение.

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

• Масштабируемость — это способность системы справляться с будущим ростом.

  Для базы данных это означает, что она должна иметь возможность быстро работать по мере увеличения числа пользователей и объемов данных.

  Масштабируемость — очень важная характеристика любой модели базы данных и СУБД.

• Организация данных в логические группы или наборы.

• Нахождение связей между наборами данных.

  Вы уже видели примеры отношений «один ко многим» и «многие ко многим».

• Минимизация избыточности данных.

Обычно базы данных нормализуются ко второй или третьей нормальной форме.

Четвертая и пятая формы используются редко.

Поэтому я ограничусь рассказом лишь о первых трёх.

11. Первая нормальная форма (1НФ).

сущность ваша система, которую вы создаете.

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

Например, в таблице клиентов каждая запись представляет одного клиента.

Основной ключ.

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

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

Социальный номер будет гораздо лучшим выбором.

Страховка как первичный ключ, поскольку это единственное поле, которое однозначно идентифицирует человека.

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

Атомность.

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

В таблице ниже хранится информация о зарегистрированных транспортных средствах.

Горизонтальное дублирование данных — плохая практика.

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

Еще один пример плохой практики проектирования — хранение нескольких значений в ячейке.

Несколько значений в одной ячейке.

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

Порядок записей не должен иметь значения.

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

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

Порядок записей неизбежно изменится по мере удаления, изменения или добавления клиентов.

Вот почему никогда не следует полагаться на порядок записей в таблице.

В следующей части мы рассмотрим вторую нормальную форму (2НФ).

12. Вторая нормальная форма.

Вторая нормальная форма связана с избыточностью данных.

Избыточность данных.

Возможно, это прозвучит немного заумно.

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

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

Дублирование данных между записями в поле магазина.

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

Если вы посмотрите на эту таблицу, вы увидите множество примеров дублирования данных среди записей.

Поле бренд можно выделить в отдельную таблицу.

Так же, как поле тип (модель), которую также можно выделить в отдельную таблицу, которая будет иметь отношение «многие к одному» с таблицей.

бренд потому что у бренда могут быть разные модели.

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

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

отношение внешнего ключа .

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

В примере выше таблицы машина имеет внешний ключ – ссылку на таблицы тип И магазин .

Столбец «Бренд» исчез, поскольку в таблице неявно упоминается бренд. тип .

Когда есть ссылка на тип, есть и ссылка на бренд, потому что тип принадлежит бренду.

Из нашей модели базы данных существенно исключена избыточность данных.

Если вы достаточно привередливы, то, возможно, вас пока не устроит такое решение.

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

Тщательный разработчик базы данных должен выделить названия стран в отдельную таблицу.

страна .

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

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

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

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

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

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

Даже если еще нет машин с таким цветом , вам нужно иметь эти цвета в базе данных, чтобы работники могли их выбирать.

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

13. Третья нормальная форма.

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

Чтобы база данных находилась в третьей нормальной форме, она должна находиться во второй нормальной форме.

Транзитивные зависимости.

Таблица клиентов (мои клиенты — игроки футбольных команд Германии и Франции) ниже содержит транзитивные зависимости.

В этой таблице не все поля зависят исключительно от первичного ключа.

Между полем postal_code и полями города и провинции существует отдельная связь.

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

Таким образом, нет необходимости хранить город и провинцию в таблице клиентов.

Если вы знаете почтовый индекс, то вы уже знаете город и провинцию.

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

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

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

Именно поэтому такие столы часто продаются.

Другим примером использования третьей нормальной формы является (слишком) простой пример таблицы заказов в интернет-магазине ниже.

НДС (налог на добавленную стоимость) — это процент, который добавляется к цене товара (19% в этой таблице).

Это означает, что значение total_ex_vat можно вычислить из значения total_inc_vat и наоборот. Вы должны хранить в таблице одно из этих значений, а не оба.

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

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

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

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

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

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

В последнем примере НДС я бы использовал третью нормальную форму.

Хранилище данных, воспроизведено из существующих , обычно это плохая идея.

Теги: #sql #MySQL #проектирование баз данных #MySQL #sql

• Врачи Без Границ

  19 Oct, 24

• Почему Основатель Paypal Макс Левчин Никогда Не Оставляет Свой Велосипед

  19 Oct, 24

• Robot Framework Для Автоматизации Тестирования: Ограничения И Преимущества

  19 Oct, 24

• Самостоятельное Изучение Схемотехники. Базовые Концепты. Часть 1

  19 Oct, 24

• Возрождение Медлительного Samsung Galaxy Tab 2 Wifi

  19 Oct, 24

• Википедия Купается В Деньгах? — Взгляд Из России

  19 Oct, 24

• Fortinet Security Fabric На Практике. Часть 4. Взаимная Интеграция

  19 Oct, 24

• Идеальный Смартфон. Мысли По Мере Развития Жизни

  19 Oct, 24

• Обучение В Голландии: Стипендии, Проживание, Виза И Работа Во Время Учебы

  19 Oct, 24

• Как Вы Ищете Адресную Информацию Компаний, Предоставляющих Интересующий Вас Продукт Или Услугу?

  19 Oct, 24