Задача нормализации
Ранее мы встретились с чисто механическим переходом от иерархической структуры к реляционной и назвали этот процесс нормализацией.
Но такая нормализация не дает оптимальной двумерной структуры. Могут возникнуть неприятности, приводящие к потерям данных.
В качестве неудачно спроектированной рассмотрим таблицу ZAKAZ. Что неправильно? В нее включено поле «Реквизиты» заказчика, значение которого зависит от значения кода заказчика, но не зависит от ключа таблицы- номера заказа. Появляется возможность потери информации- при удалении заказа (обычная операция) будут утрачены и сведения о реквизитах заказчика (если это единственный заказ этого заказчика). Если у одного заказчика заказов много, то нужно как-то избежать повторного их ввода.
Выход - в удалении поля «Банк_рек» и включении его, с добавлением кода заказчика в качестве ключа в таблицу- словарь SLZAK. Получится, что одно поле в словаре будет обслуживать много полей в основной таблице. Кроме этого словарь можно использовать и с другими таблицами, в которых есть поле «Код_зак».
Таким образом, один из основных принципов оптимальности нормализации является исключение из таблицы полей, которые не связаны непосредственно с главным ключом.
Если применить этот принцип снова к тому же примеру - обнаружим еще поле «Цена»- его значение является функцией поля «Код_прод», поэтому следует поступить аналогично «Реквизитам» - сделать словарем.
Последнее поле «Стоимость» также является лишним, поскольку его значение- вычислимо и равно произведению цены на объем, поэтому его не нужно хранить в БД.
Таким образом, после вынесения третьего и седьмого полей в словари мы получим оптимально-компромиссное решение. Компромисс заключается, с одной стороны, в полноте нормализации, с другой - в минимизации числа таблиц.
Выводы:
Практические правила нормализации, связанные с выбором полей и главного ключа следующие:
1.Правильно выбрать главный ключ (убедиться, что не могут существовать двух записей с одинаковым значением главного ключа).
2.Если главный ключ не просматривается - подумать, правильно ли подобран состав полей.
3.Если главный ключ правилен, то в качестве полей можно дописывать любые атрибуты, зависящие только от него.
Дата добавления: 2014-11-29; просмотров: 730;