|
|
Проблемы реляционного подхода 14.11.1
| Мы уже говорили, что процесс превращения иерархической или сетевой структуры данных в реляционную называется норма¬лизацией. Внешне эта операция очень проста, но содержит неко¬торые нюансы, игнорирование которых может привести к не¬приятностям. Нюансы эти заключаются в том, что даже для про¬стых двумерных структур приходится подправлять состав полей. Существует строгая теория нормализации, однако смысл ее можно понять на простых примерах. 1
Таблицу ЗАКАЗЫ (табл. 14.3, п. 14.8) мы намеренно спроекти¬ровали плохо. Это черновой набросок, список данных, который обычно создает разработчик прежде, чем взяться за нормализа¬цию.
Например, мы включили в нее поле АДРЕС КЛИЕНТА, значе¬ние которого зависит от значения кода клиента, но не зависит от ключа нашей таблицы — номера заказа. В таком случае обычно говорят о возможности потери информации: если из таблицы удалить заказ с каким-то номером, будут утрачены и сведения об адресе клиента. Однако важнее другое: повторяя многократно одни и те же данные (наименование клиента и адрес), мы не только проделаем массу лишней работы, но и неминуемо оши-
бемся (и не один раз). Поэтому следует удалить поля НА-ИМЕНОВАНИЕ КЛИЕНТА и АДРЕС КЛИЕНТА из таблицы ЗАКАЗЫ И ЙКЛЮЧИТЬ его в классификатор (словарь) КЛИЕНТЫ, имеющий три поля — код, наименование и адрес клиента. В этом словаре реквизиты конкретного клиента будут указаны только один раз. В дальнейшем их можно использовать -не только с таблицей ' ЗАКАЗЫ, НО И С другими таблицами, в которых имеется код кли¬ента.
При наличии небольшого навыка разработчик ведет нормали¬зацию и устраняет ее погрешности «интуитивными» способами. Самое главное, следует стремиться к исключению из таблицы полей, которые не связаны непосредственно с первичным ключом таблицы.
Продолжив рассмотрение таблицы ЗАКАЗЫ, МЫ обнаружим еще три лишних поля:
название продукта;
цена продукта;
стоимость продукта.
Значения первых двух полей не зависят от номера заказа, но зависят от кода продукта. Поэтому и место этих полей — в клас¬сификаторе ПРОДУКТЫ (код, название, цена).
Значение поля СТОИМОСТЬ — это произведение цены на ко¬личество, поэтому его вообще не следует включать в таблицы: система обязана при необходимости просто вычислить стоимость заказа.
Таким образом, в результате нормализации исходной таблицы ЗАКАЗЫ МЫ получили три таблицы:
одну оперативную таблицу ЗАКАЗЫ (номер заказа, код кли-ента, код продукта, количество и дата поставки);
классификатор КЛИЕНТЫ (код клиента, наименование кли-ента и адрес клиента);
классификатор ПРОДУКТЫ (код продукта, название продук-та, цена).
Помните, что каждая таблица — это всегда набор объектов (в нашем случае — заказов, клиентов и продуктов). В системе «Заказы» первая таблица является оперативной, а остальные — справочными. Оперативная таблица меняется часто (это перечень текущих заказов), а справочники — редко, их легко выправить раз и навсегда, внося в дальнейшем лишь небольшие изменения. |
| Категория: компьютеры 7 | Добавил: sergei4 (23.11.2010)
|
| Просмотров: 194
| Рейтинг: 0.0/0
|
|
|
