Что обеспечивает отсутствие избыточности данных в бд
IT-блог о веб-технологиях, серверах, протоколах, базах данных, СУБД, SQL, компьютерных сетях, языках программирования и создание сайтов.
Проектирование баз данных. Информационная избыточность. Избыточность данных в базе данных. Проблемы возникающие из-за информационной избыточности
Здравствуйте, уважаемые посетители моего скромного блога для начинающих вебразработчиков и web мастеров ZametkiNaPolyah.ru. Продолжаем сегодня рубрику Заметки о MySQL, в которой я успел описать установку MySQL сервера, настройку MySQL сервера и файл my.ini, а также поговорил о видах и типах баз данных. Сегодня я хотел бы поговорить об аномалиях в базе данных и проблеме избыточности данных в базе данных, то есть о избыточности информации.
Как и обещал, эта статья и следующая тоже будут посвящены проектированию баз данных, моделированию баз данных или созданию баз данных, как хотите, так и называйте. Данная публикация посвящена проблемам, которые могут возникнуть при проектирование базы данных, точнее одной из проблем.
Попытаюсь рассказать, как обычно на пальцах, что такое информационная избыточность и избыточность данных в базе данных. Также попытаюсь рассказать о проблемах обработки данных, которые могут возникнуть из-за избыточности информации, затрону тему целостности данных в базе данных. Немного затрону тему нормализации базы данных и нормальных форм, нормальные формы – это тема следующей публикации. Какие нормальные формы бывают и как привести базу данных к нормальной форме. Всё это вы найдете в следующей публикации.
Избавиться от избыточности данных, а следовательно и от аномалий баз данных – это вопрос проектирования баз данных. И решать вопрос устранения избыточности в базе данных следует до того, как вы начали ее реализовывать программно, то есть, до того как начали создавать базу данных в той или иной СУБД, в нашем случае СУБД MySQL.
Чтобы избавиться от информационной избыточности, а вместе с тем решить проблему модификации, удаления и добавления данных вам не потребуется каких-либо специальных программ, достаточно будет представлять структуру проектируемого объекта(заметьте, пока еще не структуру базы данных), иметь под рукой несколько чистых листов бумаги, карандаш или ручку. Но, чтобы начать от чего-то избавляться, нужно знать суть самой проблемы, из-за чего эта проблема возникает и так ли она для вас критична.
Из-за избыточности информации в базе данных возникают не только проблемы модификации, добавления и удаления данных из базы данных, но и остро встает вопрос экономии места на диске, согласитесь глупо хранить одну и ту же информацию в разных местах. Избыточность баз данных тесно связана с нормальными формами. Точнее, информационная избыточность – это отрицательный фактор, влияющий на целостность базы данных, вынуждающий нас приводить свои базы данных к нормальной форме.
Данная публикации как раз и предназначена для тех, кто хочет быстро разобраться с тем, что такое информационная избыточность и избыточность данных в базе данных, а так же тем, кто хочет разобраться с вопросом, как избавиться от избыточности данных.
Информационная избыточность. Избыточность базы данных. Что такое избыточность.
Начнем мы с информационной избыточности и избыточности реляционных баз данных в частности. Поскольку, эта самая избыточность и заставляет нас нормализовывать базы данных.
Для начала напишу умное определение избыточности, а затем постараюсь объяснить его по-русски.
Информационная избыточность – термин из теории информации, означающий превышение количества информации, используемой для передачи или хранения сообщения, над его информационной энтропией.
Давайте начнем разбираться с определением избыточности и начнем с термина информационная энтропия.
Информационная энтропия – это мера неопределенности информации, неопределенность появления какого-либо символа. Данное определение появилось в теории электросвязи. Для администратора баз данных информационную энтропию следует интерпретировать немного по-другому: информационная энтропия всё также мера неопределенности информации, но, какая информационная неопределенность может возникнуть в базе данных?
Например, у нас есть база данных, в которой хранится библиотека и есть писатель Иванов И.И., сколько книг написал Иванов И.И.? Бог его знает. Может одну, а может и сто. И сколько раз появится этот Иванов И.И. в нашей таблице, мы не знаем. Такая вот неопределенность информации.
Любая база данных предназначена для хранения информации. И при проектирование базы данных следует учесть то, что какая-то информация может повторяться несколько раз. А каждая повторяющаяся запись – это занятое место на диске. То есть превышение количества информации необходимого для хранения данных.
Конечно, можно сказать, что сейчас, с появлением терабайтных накопителей отпала необходимость экономить место на диске. Но информационная избыточность ведет не только к увеличению требуемого объема памяти для хранения информации содержащейся в базе данных.
Избыточность данных в базе данных – это нежелательное явление еще и потому, что при работе с таблицами базы данных (которые еще называют отношениями), содержащими избыточные данные возникают проблемы связанные с обработкой информации, эти проблемы называются аномалии. Про аномалии баз данных читайте в следующем разделе.
Последствия информационной избыточности в базе данных. Избыточность данных. Аномалии (проблемы) в базе данных.
Как мы уже выяснили, избыточность информации ведет не только к тому, что требуется увеличение объема накопителей, но и приводит к аномалиям в базе данных.
Аномалии в базе данных – это проблемы связанные с обработкой информации, а точнее с удаление данных из базы данных, с модификацией данных в таблице базы данных и аномалия добавления данных в базу данных.
Как вы поняли, в базе данных есть три аномалии:
Все эти проблемы связаны с целостностью баз данных, а именно с избыточностью данных в базе данных. Давайте остановимся подробней на каждой аномалии.
Давайте посмотрим на примере приближенном к реальности, что такое избыточность данных. Допустим, у нас есть таблица, в которой хранятся данные список преподавателей и список предметов, которые они ведут. Естественно, в это таблице присутствует информационная избыточность.
Таблица с информационной избыточностью
Избыточность данных в этой таблице заключается в том, что любой преподаватель может вести несколько предметов, как преподаватель Иванов и для каждого нового предмета приходится добавлять новые записи в таблицу.
Один преподаватель может вести разные предметы, а разные предметы могут вести разные преподаватели. Давайте посмотрим, какие аномалии могут произойти в данном конкретном случае и как можно избавиться от аномалий в конкретном случае.
Аномалия включения. Проблема добавления данных в базу данных.
Избыточность данных очевидна, поскольку произошло дублирование информации, преподаватель Иванов ведет два предмета и его пришлось вписать дважды в таблицу. Но это еще не всё. Допустим, в нашей школе появился новый предмет и мы хотим его добавить в существующую таблицу базы данных, но мы еще не нашли преподавателя для этого предмета. А вписать в таблицу предмет нужно уже сейчас.
В этом случае мы должны присвоить значение NULL каждому атрибуту преподавателя, но делать это никак нельзя, так как атрибут «Код преподавателя» является первичным ключом отношения (первичным ключом таблицы). Результатом попытки создания такой записи будет нарушение целостности данных базы данных, а любая СУБД, в том числе и СУБД MySQL отклонит подобную попытку создания такой записи.
Все вышеописанное является аномалией включения. Чтобы избавиться от аномалии включения нужно разбить таблицу на две: таблица преподавателей и таблица предметов. Примерно это будет выглядеть так:
Избавляемся от избыточности данных в базе данных.
Здесь мы разделили общую таблицу, тем самым избавились от аномалии включения и от возникшей информационной избыточности, то есть от дублирования в базе данных. В принципе то, что мы сделали в данный момент – привели базу данных ко второй нормальной форме.
Вторая нормальная форма позволяет нам избавиться от аномалии включения, а также от дублирования информации в базе данных, то есть мы избавляемся от избыточности информации.
Аномалия модификации. Проблема изменения базы данных.
Следующая проблема, которая может возникнуть из-за избыточности базы данных – это проблема внесения изменений в таблицы базы данных или как ее еще называют – аномалия модификации.
В нашем примере проблема модификации могла бы возникнуть при попытке изменения фамилий преподавателей, например, если бы в этом списке была незамужняя женщина с фамилией Сидорова, то возможно, когда-нибудь она вышла бы замуж и поменяла фамилию, а оператору пришлось бы для каждой записи, в которой имелась фамилия Сидорова заменить на новую фамилию. Это довольно нудная работа. Каждая такая запись или строка таблицы базы данных называется кортежем.
Чтобы избавиться от аномалии модификаций и все связанные с ней проблемы мы можем прибегнуть к предыдущему способу, просто разбиваем одну большую таблицу на две маленьких. То есть, приводим базу данных ко второй нормальной форме или просто нормализуем.
И опять же, таким образом мы избавляемся от дублирования данных в базе данных. Все довольно просто.
Аномалия удаления. Проблема удаления данных из базы данных.
Проблема удаления данных из базы данных – это еще одна проблема, которая появляется, если данные в базе избыточны ее еще называют аномалия удаления. Проблема удаления данных из базы данных заключается в том, что при удаление одной записи или кортежа из таблицы, относящейся к какому-либо из преподавателю, вместе с записью о преподавателе, из базы данных удалится вся информация о предмете, который вел этот преподаватель.
Решается проблема удаления данных из базы данных очень просто, нормализуем базу данных до второй нормальной формы, то есть разделяем таблицу на две, как это показано в разделе посвященном аномалии включения.
Обратите внимание: типы данных у различных СУБД могут быть разными, у MySQL типы данных одни, у какой-либо другой СУБД могут быть другие типы данных, как и у языков программирования. У JavaScript типы данных одни, а у PHP типы данных другие.
Руководство по проектированию реляционных баз данных (10-13 часть из 15) [перевод]
Продолжение.
Предыдущие части: 1-3, 4-6, 7-9
10. Нормализация баз данных
Указания для правильного проектирования реляционных баз данных изложены в реляционной модели данных. Они собраны в 5 групп, которые называются нормальными формами. Первая нормальная форма представляет самый низкий уровень нормализации баз данных. Пятый уровень представляет высший уровень нормализации.
Вот некоторые из основных пунктов, которые связаны с нормализацией баз данных:
Очень малое количество баз данных следуют всем пяти нормальным формам, предоставленным в реляционной модели данных. Обычно базы данных нормализуются до второй или третьей нормальной формы. Четвертая и пятая формы используются редко. Поэтому я ограничусь тем, чтобы рассказать вам лишь о первых трех.
11. Первая нормальная форма (1НФ)
Первая нормальная форма гласит, что таблица базы данных – это представление сущности вашей системы, которую вы создаете. Примеры сущностей: заказы, клиенты, заказ билетов, отель, товар и т.д. Каждая запись в базе данных представляет один экземпляр сущности. Например, в таблице клиентов каждая запись представляет одного клиента.
Первичный ключ.
Правило: каждая таблица имеет первичный ключ, состоящий из наименьшего возможного количества полей.
Как вы знаете, первичный ключ может состоять из нескольких полей. Вы, к примеру, можете выбрать имя и фамилию в качестве первичного ключа (и надеяться, что эта комбинация будет уникальной всегда). Будет намного более хорошим выбором номер соц. Страхования в качестве первичного ключа, т.к. это единственное поле, которое уникальным образом идентифицирует человека.
Еще лучше, когда нет очевидного кандидата на звание первичного ключа, создайте суррогатный первичный ключ в виде числового автоинкрементного поля.
Атомарность.
Правило: поля не имеют дубликатов в каждой записи и каждое поле содержит только одно значение.
Возьмем, например, сайт коллекционеров автомобилей, на котором каждый коллекционер может зарегистрировать его автомобили. Таблица ниже хранит информацию о зарегистрированных автомобилях.
Горизонтальное дублирование данных – плохая практика.
С таким вариантом проектирования вы можете сохранить только пять автомобилей и если у вас их менее 5, то вы тратите впустую свободное место в базе данных на хранение пустых ячеек.
Другим примером плохой практики при проектировании является хранение множественных значений в ячейке.
Множественные значения в одной ячейке.
Верным решением в данном случае будет выделение автомобилей в отдельную таблицу и использование внешнего ключа, который ссылается на эту таблицу.
Порядок записей не должен иметь значение.
Правило: порядок записей таблицы не должен иметь значения.
Вы можете быть склонны использовать порядок записей в таблице клиентов для определения того, какой из клиентов зарегистрировался первым. Для этих целей вам лучше создать поля даты и времени регистрации клиентов. Порядок записей будет неизбежно меняться, когда клиенты будут удаляться, изменяться или добавляться. Вот почему вам никогда не следует полагаться на порядок записей в таблице.
В следующей части рассмотрим вторую нормальную форму (2НФ).
12. Вторая нормальная форма.
Для того, чтобы база данных была нормализована согласно второй нормальной форме, она должна быть нормализована согласно первой нормальной форме. Вторая нормальная форма связана с избыточностью данных.
Избыточность данных.
Правило: поля с не первичным ключом не должны быть зависимы от первичного ключа.
Может звучать немного заумно. А означает это то, что вы должны хранить в таблице только данные, которые напрямую связаны с ней и не имеют отношения к другой сущности. Следование второй нормальной форме – это вопрос нахождения данных, которые часто дублируются в записях таблицы и которые могут принадлежать другой сущности.
Дублирование данных среди записей в поле store.
Таблица выше может принадлежать компании, которая продает автомобили и имеет несколько магазинов в Нидерландах.
Если посмотрите на эту таблицу, то вы увидите множественные примеры дублирования данных среди записей. Поле brand могло бы быть выделено в отдельную таблицу. Также, как и поле type (модель), которое также могло бы быть выделено в отдельную таблицу, которая бы имела связь многие-к-одному с таблицей brand потому, что у бренда могут быть разные модели.
Колонка store содержит наименование магазина, в котором в настоящее время находится машина. Store – это очевидный пример избыточности данных и хороший кандидат для отдельной сущности, которая должна быть связана с таблицей автомобилей связью по внешнему ключу.
Ниже пример того, как бы вы моги смоделировать базу данных для автомобилей, избегая избыточности данных.
В примере выше таблица car имеет внешний ключ – ссылку на таблицы type и store. Столбец brand исчез потому, что на бренд есть неявная ссылка через таблицу type. Когда есть ссылка на type, есть ссылка и на brand, т.к. type принадлежит brand.
Избыточность данных была существенным образом устранена из нашей модели базы данных. Если вы достаточно придирчивы, то вы, возможно, еще не удовлетворены этим решением. А как насчет поля country_of_origin в таблице brand? Пока дубликатов нет потому, что есть только четыре бренда из разных стран. Внимательный разработчик базы данных должен выделить названия стран в отдельную таблицу country.
И даже сейчас вы не должны быть удовлетворены результатом потому, что вы также могли бы выделить поле color в отдельную таблицу.
Насколько строго вы подходите к созданию ваших таблиц – решать вам и зависит от конкретной ситуации. Если вы планируете хранить огромное количество единиц автомобилей в системе и вы хотите иметь возможность производить поиск по цвету (color), то было бы мудрым решением выделить цвета в отдельную таблицу так, чтобы они не дублировались.
Существует другой случай, когда вы можете захотеть выделить цвета в отдельную таблицу. Если вы хотите позволить работникам компании вносить данные о новых автомобилях вы захотите, чтобы они имели возможно выбирать цвет машины из заранее заданного списка. В этом случае вы захотите хранить все возможные цвета в вашей базе данных. Даже если еще нет машин с таким цветом, вы захотите, чтобы эти цвета присутствовали в базе данных, чтобы работники могли их выбирать. Это определенно тот случай, когда вам нужно выделить цвета в отдельную таблицу.
13. Третья нормальная форма.
Третья нормальная форма связана с транзитивными зависимостями. Транзитивные зависимости между полями базы данных существует тогда, когда значения не ключевых полей зависят от значений других не ключевых полей. Чтобы база данных была в третьей нормальной форме, она должна быть во второй нормальной форме.
Транзитивные зависимости.
Правило: не может быть транзитивных зависимостей между полями в таблице.
Таблица клиентов (мои клиенты – игроки немецкой и французской футбольной команды) ниже содержит транзитивные зависимости.
В этой таблице не все поля зависят исключительно от первичного ключа. Существует отдельная связь между полем postal_code и полями города (city) и провинции (province). В Нидерландах оба значение: город и провинция – определяются почтовым кодом, индексом. Таким образом, нет необходимости хранить город и провинцию в клиентской таблице. Если вы знаете почтовый код, то вы уже знаете город и провинцию.
Такая транзитивной зависимости следует избегать, если вы хотите, чтобы ваша модель базы данных была в третьей нормальной форме.
В данном случае устранение транзитивной зависимости из таблицы может быть достигнуто путем удаления полей города и провинции из таблицы и хранение их в отдельной таблице, содержащей почтовый код (первичный ключ), имя провинции и имя города. Получение комбинации почтовый код-город-провинция для целой страны может быть весьма нетривиальным занятием. Вот почему такие таблицы зачастую продаются.
Другим примером для применения третьей нормальной формы может служить (слишком) простой пример таблицы заказов интернет-магазина ниже.
НДС (value added tax) – это процент, который добавляется к цене продукта (19% в данной таблице). Это означает, что значение total_ex_vat может быть вычислено из значения total_inc_vat и vice versa. Вы должны хранить в таблице одно из этих значений, но не оба сразу. Вы должны возложить задачу вычисления total_inc_vat из total_ex_vat или наоборот на программу, которая использует базу данных.
Третья нормальная форма гласит, что вы не должны хранить данные в таблице, которые могут быть получены из других (не ключевых) полей таблицы. Особенно в примере с таблицей клиентов следование третьей нормальной форме требует либо большого объема работы, либо приобретения коммерческой версии данных для такой таблицы.
Третья нормальная форма не всегда используется при проектировании баз данных. Когда разрабатываете базу данных вы всегда должны сравнивать преимущества от более высокой нормальной формы в сравнении с объемом работ, которые требуются для применения третьей нормальной формы и поддержания данных в таком состоянии. В случае с клиентской таблицей лично я бы предпочел не нормализовать таблицу до третьей нормальной формы. В последнем примере с НДС я бы использовал третью нормальную форму. Хранение данных, воспроизводимых из существующих, обычно плохая идея.
Избыточность данных и её оптимизация
Эта статья расскажет о том, что такое избыточность базы данных, и как использовать её для повышения производительности.
Избыточность RAID-массива
Избыточность RAID-массива – пожалуй, самый распространённый вид избыточности. RAID расшифровывается как «redundant array of independent disks» (избыточный массив независимых дисков), это значит, что в большинстве конфигураций диски так или иначе зеркалируют друг друга.
Зеркальный массив RAID 1 – базовая реализация избыточности RAID. Он состоит из нескольких (как правило, двух) дисков, которые полностью копируют друг друга. Если один из дисков выходит из строя, вся поддержка, обслуживание и запись данных выполняется вторым диском. Такой массив позволяет ускорить операции чтения, поскольку система может читать данные с любого диска.
В принципе, этот пример относится ко всем RAID-массивам. Теперь особенно хорошо заметно различие между RAID и резервными копиями: любое изменение диска применяется ко всем дискам сразу; то есть, если файл был удалён с одного диска, его сразу не станет и на втором.
Блочная избыточность
Следующий вид избыточности – зеркалирование целых блочных структур. Для этого используется DRBD (distributed replicated block device).
Этот метод чем-то похож на избыточность массивов RAID. Разница заключается в том, где происходит репликация. В RAID-массива, избыточность происходит на уровне приложения. Программное обеспечение RAID управляет физическими устройствами хранения и предоставляет данные приложения с одного из доступных устройств.
Настройки DRBD совсем другие. При этом полностью зеркалируется каждый аппаратный стек, а также каждый интерфейс приложения. Это означает, что так можно исправить отказ приложения, потому что, по сути, есть ещё одна отдельная машина с копией данных, необходимых для работы. Если у первого сервера выходит из строя блок питания, второй сервер будет по-прежнему эффективно работать.
Репликация SQL
При работе с базами данных SQL (MySQL, MariaDB, PostgreSQL и т.п.) можно использовать их встроенные функции репликации, чтобы обеспечить отказоустойчивость в случае сбоя основного сервера.
Репликация по типу Master-Slave
Это, пожалуй, самый базовый вид репликации данных SQL. В такой настройке есть один главный сервер, который называется ведущим, или master-сервером. Этот сервер отвечает за все операции записи и обновления данных. Затем данные с этого сервера копируются на ведомый сервер (или slave-сервер).
Эта настройка позволяет распределить операции чтения между несколькими машинами, что может значительно улучшить производительность приложения.
Конечно, увеличение производительности является важным преимуществом; однако не менее важно то, что такая репликация повышает отказоустойчивость. Если master-сервер по какой-либо причине недоступен, операции чтения могут выполняться на серверах slave. Более того, slave-сервер можно перенастроить в master-сервер в случае, если предыдущий master недоступен в течение длительного периода.
Именно на примере репликации master-slave можно увидеть, как репликация данных и резервное копирование могут дополнять друг друга. При такой настройке можно реплицировать данные от ведущего сервера к ведомому. Затем можно временно отключить репликацию, чтобы сохранить данные на slave-сервере в согласованном состоянии, и создать резервную копию базы данных при помощи любого удобного механизма
Примечание: Подробнее о настройке репликации данных по типу master-slave можно прочесть в руководствах:
Репликация по типу master-master
В такой настройке репликации каждый сервер является ведущим, то есть master. Это значит, что каждый сервер может принимать и обновлять данные, после чего изменения будут распространены на остальные серверы. Такая репликация имеет те же преимущества, что и master-slave, и, кроме того, позволяет увеличить производительность с помощью механизма балансировки нагрузки.
Таким образом, если один сервер выходит из строя, то другой может еще и принимать запросы. Конечно, такая конфигурация сложнее, зато она гораздо отказоустойчивее, ведь в случае сбоя не нужно перенастраивать серверы (как при репликации master-slave).
Эту настройку можно совместить с механизмами резервного копирования; для этого нужно отключить один из master-серверов, поскольку во время резервного копирования данные должны находиться в согласованном состоянии. После завершения резервного копирования можно возобновить репликацию.
Примечание: Подробнее о настройке репликации master-master можно прочесть здесь.
Распределение как альтернатива избыточности
Распределенные системы обладают многими преимуществами традиционных настроек избыточности.
Ранее в данном руководстве упоминались RAID-массивы, в частности RAID 1. Ещё один распространённый массив – это RAID 5. Он распределяет данные между несколькими накопителями, а также ведёт контроль по чётности. Информация о чётности хранится на отдельном контрольном диске. Это означает, что в случае отказа одного из дисков любая транзакция может быть восстановлена путём объединения информации о четности на других дисках.
Также существует немало баз данных и других программных решений, предназначенных для распределения данных.
В качестве примера можно привести Riak; это распределенная база данных. Ноды Riak работают точно так же. Между ними нет отношений типа ведущий-ведомый. Объекты, хранящиеся в базе данных, реплицируются.
Однако ноды при этом не содержат полной БД, данные равномерно распределяются между ними. Объекты после репликации размещаются на разных нодах, чтобы обеспечить доступ к данным в случае аппаратных сбоев.
Другим хорошим примером этого подхода является распределённая БД Cassandra. Она основана на тех же принципах, что и Riak, но реализована немного иначе.
Примечание: В следующих статьях можно найти дополнительную информацию по распределённым БД:
Заключение
Как видите, существует множество возможностей для оптимизации работы сервера при помощи избыточности данных. в основном, подход зависит от проблем, которые нужно устранить или предупредить. Кроме того, эти техники можно комбинировать.
Также это руководство хорошо иллюстрирует, что избыточность не заменяет резервное копирование, и наоборот. Избыточные системы всегда в работе и всегда зеркалируют изменения, а это может привести к полной потере данных.
Приложениям, в которых доступ и целостность данных имеют большое значение, необходимо и резервное копирование, и настройка избыточности. Надлежащая реализация этих механизмов гарантирует высокую производительность и надёжную защиту данных.