Повторяющиеся группы

Задача нормализации

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

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

В качестве неудачно спроектированной рассмотрим таблицу ZAKAZ. Что неправильно? В нее включено поле «Реквизиты» заказчика, значение которого зависит от значения кода заказчика, но не зависит от ключа таблицы- номера заказа. Появляется возможность потери информации- при удалении заказа (обычная операция) будут утрачены и сведения о реквизитах заказчика (если это единственный заказ этого заказчика). Если у одного заказчика заказов много, то нужно как-то избежать повторного их ввода.

Выход - в удалении поля «Банк_рек» и включении его, с добавлением кода заказчика в качестве ключа в таблицу- словарь SLZAK. Получится, что одно поле в словаре будет обслуживать много полей в основной таблице. Кроме этого словарь можно использовать и с другими таблицами, в которых есть поле «Код_зак».

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

Если применить этот принцип снова к тому же примеру - обнаружим еще поле «Цена»- его значение является функцией поля «Код_прод», поэтому следует поступить аналогично «Реквизитам» - сделать словарем.

Последнее поле «Стоимость» также является лишним, поскольку его значение- вычислимо и равно произведению цены на объем, поэтому его не нужно хранить в БД.

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

Выводы:

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

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

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

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

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

Например, «Кадры». Каждая запись описывает работника. При необходимости вести более исчерпывающую информацию, получим ситуацию, когда объем информации сильно меняется от человека к человеку (прежние места работы, командировки, научные премии, взыскания, напечатанные труды, заболеваемость и т.д.).

Если все это попросту включить в файл KADR, то число полей для каждой записи придется брать по максимуму. Например, ученый может иметь до 10 премий, тогда придется включать в общую таблицу 20 полей: ДАТА1, КОД1; ДАТА2, КОД2;… Большая часть значений этих полей будет пустой.

Подобную информацию, разную по объему для каждой записи основной таблицы называют повторяющимися группами. Решение задачи заключается в заведении отдельной таблицы со своим ключом для каждой повторяющейся группы. Например, для премий: