Что означает избыточность данных
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 или наоборот на программу, которая использует базу данных.
Третья нормальная форма гласит, что вы не должны хранить данные в таблице, которые могут быть получены из других (не ключевых) полей таблицы. Особенно в примере с таблицей клиентов следование третьей нормальной форме требует либо большого объема работы, либо приобретения коммерческой версии данных для такой таблицы.
Третья нормальная форма не всегда используется при проектировании баз данных. Когда разрабатываете базу данных вы всегда должны сравнивать преимущества от более высокой нормальной формы в сравнении с объемом работ, которые требуются для применения третьей нормальной формы и поддержания данных в таком состоянии. В случае с клиентской таблицей лично я бы предпочел не нормализовать таблицу до третьей нормальной формы. В последнем примере с НДС я бы использовал третью нормальную форму. Хранение данных, воспроизводимых из существующих, обычно плохая идея.
Классификация таблиц в реляционных базах данных по признакам целостности и избыточности данных
Содержание статьи
Обоснование статьи и некоторые ключевые понятия;
1. Справочники и связки;
1.1. Виды таблиц;
1.2. Виды справочников;
1.3. Виды связок;
2. Обобщение классификации;
2.1. Классификация в табличном виде;
2.2. Классификация в схематичном виде;
3. Некоторые комментарии по применению классификации;
3.1. Применение классификации при нормализации таблиц;
Заключение.
Обоснование статьи и некоторые ключевые понятия
Очень часто присутствовал на обучении дисциплине «Базы данных». Обучался когда-то сам… Как-то даже пришлось проводить целый курс для друзей и знакомых. Во время обучения мною было замечено, что трудности возникают уже на этапе понимания таблиц и того, как ими пользоваться. Многие просто не могли и не могут разработать простейшие базы данных. После более детального рассмотрения такого понятия как таблицы и маленькой классификации, трудности восприятия таблиц в реляционных базах данных почти всегда исчезают. Итак!
В данной статье будет рассмотрена маленькая классификация таблиц по признакам целостности и избыточности. Что это значит? Это значит, что будут приведены примеры с описанием, какую структуру таблиц можно делать, чтобы предотвращать (пытаться предотвращать) избыточность и добиваться целостности в реляционных базах данных.
Для понимания дадим краткие определения целостности и избыточности данных:
Целостность данных – это свойство способности по одним данным восстанавливать другие, при этом не теряя семантическое единство этих данных и отношения между ними (между данными).
Избыточность данных – это состояние базы данных, при котором в таблицах присутствуют лишние данные.
Целостность данных может быть нарушена в результате операций модификации данных. Если в базе данных запрещены операции удаления и обновления, то целостность может быть нарушена только в результате операции добавления, а также неправильно написанных скриптов по отображению данных.
1. Справочники и связки
1.1. Виды таблиц
Немного углубимся в маленькую классификацию таблиц по видам их структуры. Разделим таблицы на два общих вида. Первым видом будут таблицы-справочники, вторым таблицы-связки.
Рисунок 1. Справочники и связки
Информацию в таблицах можно разделить на два вида. На информацию, которая описывает объекты (субъекты), связи и информацию, которая описывает действия, процессы, события, иное.
В справочниках содержатся сведения об объектах и субъектах, связях. В связках содержатся сведения о действиях, процессах, событиях и так далее.
В связках хранятся данные, взятые из таблиц справочников. Поскольку невыгодно повторять одни и те же данные при описании объектов (субъектов) и при описании их взаимодействия, данные об объектах (субъектах) заносятся в справочники, а в таблицах-связках не хранятся данные объектов (субъектов) в чистом виде, а лишь ссылки на них (внешний ключ). Таким образом, в связках хранятся данные по взаимодействию объектов (субъектов) и ссылки на самих объектов (субъектов) (внешний ключ). Эти «ссылки» являются первичными ключами в таблицах справочниках. Но об этом потом…
Отличие справочника от связки выражается в том, что таблицы-справочники могут быть самостоятельными и независимыми (то есть, при чтении данных некоторых справочников можно в целом понять семантику), а таблицы-связки практически никогда.
1.2. Виды справочников
Справочники могут подразделяться на несколько видов. Это статичные, статично-динамичные и динамичные справочники. Разумеется, вряд ли можно назвать абсолютно статичный справочник, так как в этом мире может измениться всё. Или почти всё.
Статичный справочник – справочник, данные об объектах, субъектах, связях в котором либо никогда не подвергаются модификации после первичной модификации, либо настолько редко подвергаются модификации, что этим можно пренебречь.
Примером таких справочников могут служить список месяцев с названиями и номерами, список дней недели, список времён года, список океанов и так далее…
| Номер | Наименование |
| 1 | Январь |
| 2 | Февраль |
| 3 | Март |
| 4 | Апрель |
| 5 | Май |
| 6 | Июнь |
| 7 | Июль |
| 8 | Август |
| 9 | Сентябрь |
| 10 | Октябрь |
| 11 | Ноябрь |
| 12 | Декабрь |
Таблица 1. Пример статичных справочников
Статично-динамичный справочник – справочник, в котором хранятся данные о связях, если связи носят справочный характер. В таком справочнике могут быть внешние ключи.
Наиболее удачным примером будет таблица с такими медицинскими данными, как вес. Список человек, вес которых измеряется, изменяется не так часто. А вот данные по их весу могут меняться каждый день. Статично-динамичные справочники являются единственными справочниками, где осознанно можно повторять любую информацию. Ещё одним примером может быть справочник окладов по должностям (по коду должности).
| Код должности | Оклад | Дата обновления |
| 1001 | 12 000 | 05.02.2015 |
| 1002 | 17 000 | 01.02.2015 |
| 1003 | 11 500 | 01.02.2015 |
| 1004 | 25 450 | 01.02.2015 |
| 1005 | 10 000 | 01.02.2015 |
| 1006 | 6 000 | 04.02.2015 |
Таблица 2. Пример статично-динамичных справочников
Динамичные справочники – это таблицы, данные об объектах, субъектах, связях в которых меняются часто и используются в других таблицах. От статичных справочников отличаются только частотой модификации в них данных.
Примером таких таблиц могут быть списки проектов. На самом деле, данные об открытии или закрытии проектов могут находиться в самом справочнике проектов, что в большинстве случаев неправильно и нарушает целостность. С другой стороны, если хранить историю изменений по открытию и закрытию (приостановке) проектов, то можно получить избыточность данных. Целостность и избыточность данных будут бороться с друг другом ещё долго, также как и зима с летом.
| Код проекта | Проект | Нормативный срок выполнения | Дата добавления | Пользователь |
| PT102 | Покраска окон | 15 | 03.01.2014 | 1547 |
| PT103 | Установка дверей | 10 | 04.01.2014 | 9874 |
| PT587 | Проверка пожарных кранов | 2 | 04.01.2014 | 1456 |
| PT588 | Замена люков | 3 | 02.01.2014 | 0147 |
| PT133 | Очистка каналов | 11 | 09.02.2015 | 1547 |
Таблица 3. Пример динамичных справочников
Рисунок 2. Виды справочников
1.3. Виды связок
Таблицы-связки можно разделить на два вида.
Это справочник-связка (сразу же уточним, что справочник-связка справочником не является, назван так, потому что в нём существуют поля, которые образуют справочник, но в справочник выделены быть не могут). Таблица, в которой хранятся внешние ключи, данные, которые не являются справочными и поля, содержащие данные, которые образуют справочник, но не могут быть выделены в отдельную таблицу-справочник.
Примером справочника-связки будет являться таблица платёжных транзакций. Или таблица с данными о футбольном матче.
| Код транзакции | Плательщик | Получатель | Сумма | Дата | Комментарий |
| EEVS-doodi4 | 100045 | 57457 | -10 000 | 25.07.2014 | На сапоги |
| UDFD-ioeed9 | 455780 | 10024 | -900 | 24.06.2014 | NULL |
| PEDD-jdksl4 | 144770 | 56698 | -6980 | 01.01.2015 | NULL |
| FDFE-keiiii0 | 447757 | 1 | 120 | 08.07.2014 | NULL |
Таблица 4. Пример справочника-связки
И связка (да, просто связка). Это таблица в которой хранятся только внешние ключи и данные, которые нельзя отнести к справочным, например дата или значения логических полей.
Примером связки будет являться таблица автоматического логирования терминала обработки данных.
Кстати, легко догадаться, что связки почти нигде не используются, поскольку чаще всего находятся данные, которые могут быть записаны в базу, но не содержаться в справочниках, поэтому невозможно сопоставить им внешний ключ.
| Код | Код клиента | Показания счётчика | Месяц |
| 2334 | 35643 | 50 | 01.01.2015 |
| 2335 | 235673 | 49 | 01.01.2015 |
| 2335 | 436345 | 56 | 01.01.2015 |
| 2335 | 574733 | 24 | 01.01.2015 |
Таблица 5. Пример связки
Необходимо пояснить, что это за поля, которые образуют справочник, но не могут быть выделены в отдельную таблицу-справочник. Примером таких полей являются поля «комментарий», «жалоба», «описание», «предложение». Словом, если приводить популярный пример, то поле «сообщение» в таблице базы данных любой социальной сети…
Рисунок 3. Виды связок
2. Обобщение классификации
2.1. Классификация в табличном виде
| Вид таблицы | Описание | Примеры | Плюсы (+) | Минусы(-) |
| Статичный справочник | Таблица. Данные из неё берутся для других таблиц. Из справочника в других таблицах можно использовать только первичный ключ. В статичном справочнике должна содержаться информация, которая либо вообще не изменяется, либо изменяется так редко, что этим можно принебречь. На статичный справочник ссылаются (внешний ключ), когда нужно получить названия, обозначения, нормы, количественные или качественные показатели. Иное. | Справочник (наименований и номеров) месяцев. Справочник складов и цехов предприятия. Справочник правил игры. | Иногда заменяет системные функции СУБД, позволяет более гибко работать с некоторыми данными. В случае, если меняется редко изменяемая информация, предостерегает от серьёзных последствий. | Использование таблицы с любой структурой может замедлять работу, в случае, если таблица заменяет системное хранилише. Приходится писать дополнительные функции и обработки для данной таблицы, которые не всегда правильно оптимизированны. В некоторых случаях невозможно оптимизировать. |
| Статично-динамичный справочник | Таблица. Данные из неё берутся для других таблиц. Из справочника в других таблицах нельзя использовать внешний ключ этого справочника, однако можно использовать первичный ключ. | Справочник окладов по должностям. Справочник (размеров обуви, веса, роста, размера головы) физиологических параметров. Справочник (менеджеров, компаний) содержащий компании и менеджеров, которые эти компании обслуживают и учитывают. | Позволяет проводить гибкую нормализацию по схеме «Справочник-связка» = «Связка»+«Статично-динамичный справочник». | Справочник, выделенный из справочника-связки, никуда не девается и не имеет никакой реляционной связи, которая позволила бы ему превратиться в статичный или динамичный справочник. А значит, всегда избыточен. |
| Динамичный справочник | Таблица. Данные из неё берутся часто для других таблиц. Из справочника в других таблицах можно использовать только первичный ключ. В динамичном справочнике должна содержаться информация, которая часто изменяется. | Справочник клиентов. Справочник поставщиков. Справочник контрагентов. Справочник менеджеров компании. Справочник работников. Справочник студентов. | Позволяет хранить динамичные данные, при этом давая возможность однозначно ссылаться на них. | Чаще всего накопительного типа и не делим, что создаёт определённую избыточность. |
| Справочник-связка | Таблица. Данные из неё не могут содержаться в других таблицах, но на основе них могут быть созданы данные в других таблицах. | Платёжные транзакции. Продажи. Межзаводские перемещения. График перевозок. | Позволяет проводить гибкую нормализацию по схеме «Справочник-связка» = «Связка»+«Статично-динамичный справочник». | Справочник-связка после нормализации превращается в связку и сводит избыточность данных к минимуму, не затрагивая целостность, однако не делим и при архивировании в текущей таблице не подлежит оптимизации. |
| Связка | Таблица. Данные из неё не могут содержаться в других таблицах, но на основе них могут быть созданы данные в других таблицах. Таблица не может содержать кортежей, значения атрибутов в которых являются неделимыми и не уникальными. | Автоматический лог ошибок в программе. Лог запроса сервера. Результаты трассировок. Отчёты о выгрузке и загрузке компонентов. Автоматические отчёты системы безопасности. | Связка сводит избыточность данных к минимуму, не затрагивая целостность. | Накапливаясь, является неделимой таблицей. Сложно оптимизировать. |
Таблица 6. Классификация
2.2. Классификация в схематичном виде
Рисунок 4. Схема классификации таблиц в реляционных базах данных по признакам целостности и избыточности данных
3. Некоторые комментарии по применению классификации
3.1. Применение классификации при нормализации таблиц
Процесс нормализации, если не учитывать некоторые этапы (Но учитывать результаты этих этапов!) — это обычное «дробление» таблиц на более мелкие таблицы с созданием реляционной связи между ними непосредственно или через промежуточные таблицы (связь «Многие ко многим»). Под реляционной связью может не всегда пониматься реляционное отношение!
Преобразование динамичного или статичного справочника в статично-динамичный справочник, а справочника-связки в связку, как и статично-динамичного справочника в справочник-связку — это ни что иное, как дробление таблиц. То есть, преобразование одного вида таблиц в другой через показанную выше классификацию в целях избежания избыточности данных — так можно определить нормализацию (один из вариантов определения).
Для примера. Пусть имеется база данных, в которой единственная операция по модификации данных — это добавление. В таком случае становится неэффективным каждый раз при изменении какого либо отдельного атрибута сущности, «копировать» остальные значения атрибутов уже в другой кортеж. В этом случае используются NULL или же создание статично-динамичного справочника, где описывается ряд атрибутов одной семантики или один атрибут, а дублируется лишь внешний ключ с первичным ключом последовательности. Этот же метод может использоваться в традиционной схеме модификации данных с обновлением и удалением данных.
Заключение
Данная классификация была создана мной на основе наблюдений при проектировании баз данных, а также исходя из прочитанной теории по проектированию в реляционных СУБД. Моим друзьям и знакомым, изучающим дисциплину «базы данных» и занимающимся проектированием баз данных, и мне эта классификация достаточно серьёзно упростила «жизнь» и позволила во многих ситуациях заранее выбрать наиболее подходящий и, как оказывалось потом, правильный вид таблицы для хранения в ней тех или иных данных.
Классификация может быть расширена разделением существующих видов в ней на подвиды (возможно, даже, добавлением новых видов). Также эта классификация показала, что лучше в некоторых ситуациях не использовать тот или иной вид таблиц. Некоторые виды таблиц из данной классификации лучше использовать реже (динамичные справочники). А некоторые пытаться заменить на другие (справочники-связки на связки).
Надеюсь, кому ни будь ещё поможет эта классификация при освоении дисциплины «Базы данных» и при проектировании баз данных в реляционных СУБД.