Следует отметить, что по крайней мере в коммерческом мире термин репликация стал означать преимущественно (или даже исключительно) асинхронную репликацию (как уже отмечалось в главе 20).

Основное различие между репликацией и управлением копированием заключается в следующем. Если используется репликация, то обновление одной реплики в конечном счете распространяется на все остальные автоматически . В режиме управления копированием, напротив, не существует такого автоматического распространения обновлений. Копии данных создаются и управляются с помощью группового или фонового процесса, который разделен по времени от обновляющих транзакций. Управление копированием, в общем, более эффективно по сравнению с репликацией, поскольку за один раз могут копироваться большие объемы данных. К недостаткам можно отнести то, что большую часть времени копии данных не будут идентичны данным базы, поэтому пользователи должны знать, когда эти данные синхронизированы. Обычно управление копированием упрощается благодаря требованию, чтобы обновления применялись в соответствии со схемой первичной копии того или иного вида (см. главу 20).

Теперь рассмотрим другой вид избыточности - расчетные столбцы и итоговые таблицы. Эти конструкции особенно важны в контексте систем поддержки принятия решений. В них содержатся предварительно подсчитанные значения данных - значения, которые вычисляются на основе других данных, хранящихся где-то в базе данных. Ясно, что такие конструкции позволяют избежать необходимости каждый раз повторно вычислять эти значения, когда они понадобятся в каком-то запросе. Расчетный столбец - это такой столбец, значение которого в данной строке является производным от других значений в той же строке. Итоговая таблица - это таблица, в которой содержатся совокупные или обобщенные значения (сумма, среднее значение, количество строк и т.п.), вычисленные на основе значений в других таблицах. Такие итоги часто предварительно вычисляются для нескольких различных групп одних и тех же детальных данных (см. раздел 21.6).

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

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

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

Распространенные ошибки проектирования

в этом подразделе мы вкратце прокомментируем ошибки проектирования в среде поддержки принятия решений, которые широко распространены на практике.

Дублирование строк. Проектировщики систем поддержки принятия решений часто утверждают, что их данные просто не имеют уникальных идентификаторов, и поэтому допускается дублирование строк. В [5.3] и [5.6] подробно объясняется, почему разрешение дубликатов является ошибкой. Здесь же мы просто отметим, что эта необходимость возникает из-за того, что физическая схема не является производной от логической схемы, которая, возможно, никогда и не создавалась. Также заметим, что в таком проекте строки часто имеют неоднородное значение, в особенности если в них присутствуют NULL-значения. Иначе говоря, не все строки являются экземплярами одного и того же предиката (см. раздел 3.4 главы 3, а также главу 18).

Замечание. Иногда дубликаты допускаются преднамеренно, особенно если проектировщик использует объектно-ориентированную среду (см. последний абзац в разделе 24.2 главы 24).

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

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

Замечание. Схемы типа звезда будут подробно рассматриваться в разделе 2L5.

NULL-значения. Проектировщики часто пытаются сберечь пространство, допуская наличие в столбцах NULL-значений. Этот прием может сработать, если столбец имеет тип данных переменной длины, а NULL-значения на физическом уровне представляются пустыми строками. Однако в общем случае такие попытки будут неправильными. Не только просто возможно (и желательно) проектировать так, чтобы избежать появления NULL-значений [18.20], но это часто и существенно выгоднее, поскольку в результате память используется более эффективно и достигается более высокая производительность операций ввода-вывода.

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

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

Множественные пути доступа. Проектировщики систем поддержки принятия решений и их пользователи часто ошибочно говорят о множественности путей доступа к некоторым необходимым им данным, подразумевая, что одни и те же данные могут быть получены несколькими разными реляционными выражениями. Иногда такие выражения действительно равносильны, как в случае, например, А JOIN (В JOIN С) и (А JOIN В) JOIN С (см. главу 17). Иногда они равносильны благодаря действию некоторого офаничения целостности (снова см. главу 17), а иногда на самом деле они оказываются вовсе не равносильными. Для иллюстрации последнего случая предположим, что таблицы А, В и С имеют общий столбец К. Тогда путь следования по значениям в столбце К от А к В, а оттуда к С , определенно, не то же самое, что путь следования по значениям в столбце К напрямую от А к С . Ясно, что в таких ситуациях пользователи могут быть поставлены в тупик. Они не знают, какое именно выражение необходимо применять и будут ли одинаковыми полученные результаты. Конечно, частично эта проблема может быть решена за счет дополнительного обучения пользователей. Еще часть проблемы можно решить за счет обеспечения правильной работы оптимизатора. Однако часть проблемы возлагается и на проектировщиков, которые разрешают избыточность в логической схеме и/или предоставляют пользователям непосредственный доступ к физической схеме. Следует отметить, что эта часть проблемы может быть решена только за счет правильного проектирования.

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

21.4. Подготовка данных

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

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