pML-операций. Он состоит в переработке запроса (см. ниже). Этот прием хорошо срабатывает сданными, которые не сильно перекошены , но он не столь хорош для атрибутов вроде заголовков рефератов и докладов, многие из которых начинаются с An или The . Этот механизм можно активизировать в Oracle Forms версий 4.0 и 4.5 (опция запроса без учета регистра). Запрос:

SELECT rec title , rec artist FROM records r WHERE r title = Brothers in Arms;

следует преобразовать таким образом.

SELECT rec title , rec artist FROM records r WHERE ( r.title LIKE Br% OR r.title LIKE br% OR r.title LIKE BR% OR r.title LIKE bR% ) AND OPPER(r.title) = OPPER(Brothers m Arms);

Денормализация методом разделяй и властвуй

Разбиение нормализованной таблицы на две и более таблиц и создание между ними отношения один к одному можно, в принципе, классифицировать как форму денормализации. Почему же это делают? Часто по причине технического характера (в данном случае у вас нет выбора). В Oracle есть следующее ограничение: таблица не может иметь больше одного столбца типа LONG или LONG RAW. Допустим, что у вас есть таблица PROGRAMS и нужно сохранить и исходный код (LONG), и объектный код (LONG RAW). Из-за вышеупомянутого ограничения в одной таблице это сделать нельзя, поэтому один из кодов нужно разместить в отдельной таблице. Ожидается, что в OracleS это условие будет смягчено. Однако на данный момент оно может заставить проектировшика разбить таблицу на две.

Иногда лучше вынести столбец LONG в отдельную таблицу, даже если вышеупомянутое ограничение не действует. Рассмотрим таблицу, строки которой представлены на рис. 4.5. Предположим, что в большинстве строк столбец LONG содержит данные. Если нет индексов по неключевым столбцам, то при выполнении запросов по любому из этих столбцов Oracle будет осуществлять полное сканирование таблицы. При этом из-за наличия в таблице столбца LONG понадобятся дополнительные операции ввода-вывода.

- ключевые столбцы

- неключевые столбцы

- столбец типа LONG

Рис. 4 5 Строка таблицы со столбцом типа LONG

Чтобы устранить эту проблему (если она действительно является проблемой - ведь мы хотели бы полностью избежать полного сканирования таблицы), разделите таблицу так, как показано на рис. 4.6. (Дополнительная информация об использовании столбцов LONG и LONG RAW предлагается в главе 5.)

Рис 4 6 Выделение столбца LONG

Опять-таки у нас есть основания рассчитывать, что в OracleS необходтг-мость в таком искусственном решении исчезнет. В данном случае значение LONG можно будет не хранить как встроенное, а держать его в дополнительной таблице , зарезервированной для этой цели.

В Oracle? таблица не может иметь более 254 столбцов, и если предложить таблицу с большим числом столбцов, то также возникнет причина для разделения такой таблицы на две. Однако мы считаем, что в любой хорошо спроектированной схеме базы данных таблицы с числом столбцов около 254 могут понадобиться только в следующих случаях:

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

системы. Конечно, в данном случае наследуется и структура, и все реляционные свойства в ней отсутствуют.

Выполняется слияние двух таблиц путем формирования в одной из них повторяющейся группы. Этот прием, применение котфого оправдано, по нашему мнению, лишь в немногих случаях, рассматривается в следующем разделе.

Речь идет о хранилище данных, в котором принято решение выполнить массовую нисходящую денормализацию. В этом случае мы рекомендуем создавать таблицы с максимальным для Oracle числом столбцов, так как любое другое решение, вероятно, обусловит необходимость массовых соединений один к одному .

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

Денормализация методом слияния таблиц

После того как мы вложили столько сил в нормализацию структур данных и разбивку сущностей, нам предлагается начать слияние таблиц? А как же все те опасности аномалий в данных, о которых мы предупреждали? Фактически, слияние оправдано в очень немногих случаях. Помните, что этот метод, как правило, не следует использовать для того, чтобы избежать соединения - вне хранилищ данных соединения не так уж и плохи.

Один из примеров обоснованного применения слияния - наличие повторяющейся группы, которая гарантированно состоит из фиксированного числа элементов. Хорошими кандидатами на такое объединение являются таблицы со строкой для каждого месяца года или каждого дня недели. В приведенном ниже примере представлена упрощенная система регистрации очков в гольфе. Предполагая, что в раунде не более 18 лунок (причем здесь возможна ошибка), мы можем реализовать таблицу SCORE ( Счет ) с одной строкой на раунд, а не с 19 строками на раунд (заголовок плюс 18 записей). Такая реализация показана на рис. 4.7 и 4.8.

PLAYER I SCORE t HOLE

NAME ко I- NUMBER

Puc 4 7 Простая модель регистрации очков в гольфе

В чем преимущество такой реализации? В нашем простом случае ощутимого преимущества может и не быть. Однако следует отметить, что мы можем вычислить сумму по раунду (либо первых, либо последних девяти лунок), обратившись всего к одной строке. Это может быть очень важно, если мы