Главная » SQL, Базы данных » ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ ДЛЯ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ

0

: Как было указано ранее, в частности, во введении к части III, по мнению автора, проект базы данных всегда должен выполняться на двух уровнях: логическом и физическом, как описано ниже.

1.  Прежде всего, должен быть выполнен логический проект. На этом уровне основ ное внимание уделяется правильности реляционных определений. Таблицы должны представлять правильные отношения, гарантируя таким образом, что реляцион ные операции будут выполняться так, как им надлежит выполняться, и не будет получено никаких непредвиденных результатов. Затем должны быть описаны ти пы (домены), на их основе определены столбцы и указаны зависимости между столбцами (в том числе функциональные и другие зависимости). На основании этих данных может быть выполнена нормализация и определены дополнительные ограничения целостности.

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

Безусловно, логическая схема может быть впоследствии изменена, например, в целях включения новых видов данных, а также новых или вновь обнаруженных зависимостей. Внесенные изменения, естественно, потребуют также соответствующих изменений в физической схеме. Но этот вопрос в данной  главе  не рассматривается. Здесь нас больше интересует то, что физическая схема может изменяться, в то время как логическая схема будет оставаться прежней. Например, предположим, что операция соединения таблиц SP (Поставки) и Р (Детали) в значительной степени применяется намного чаще по сравнению с другими операциями доступа к данным. Тогда может возникнуть стремление выполнить предварительное соединение таблиц SP и Р на физическом уровне, чтобы сократить тем самым количество операций ввода-вывода и расходы на соединение этих таблиц. Но логическая схема должна оставаться неизменной, если мы хотим сохранить физическую независимость от данных. (Безусловно, оптимизатор  запросов должен иметь информацию о существовании хранимого предварительного соединения и действовать соответствующим образом, чтобы  достичь желаемого  повышения  производительности.) Кроме того, если модель  доступа в дальнейшем изменится таким образом, что станет преобладать доступ к отдельным таблицам, а не к соединению, должна существовать возможность вновь изменить физическую схему, чтобы физически разъединить таблицы SP и р, опять-таки, без какого-либо воздействия на логический уровень.

Из сказанного выше должно быть ясно, что проблема обеспечения независимости от физических данных — это в основном проблема поддержки  представлений (исключая проблему обновления фрагментов, рассматриваемую в главе 21, которая проявляется на

другом участке общей архитектуры системы). В частности, необходимо иметь возможность обновлять такие представления. А именно, если базовые таблицы рассматриваются на логическом уровне как представления, а хранимые версии этих представлений на физическом уровне рассматриваются как таблицы, то должна применяться такая физическая схема, чтобы СУБД позволяла осуществлять операции обновления этих представлений в терминах указанных базовых таблиц.

Итак, как показано в главе 9, теоретически все представления являются обновляемыми. Поэтому, с теоретической точки зрения, если физическая схема разработана на основе логической схемы по принципу, описанному выше, то  может быть достигнута максимальная физическая независимость от данных. Любое обновление, выраженное в терминах логической схемы, будет автоматически преобразовано в обновление, выраженное в терминах физической схемы, и наоборот, а сами изменения физической схемы не будут требовать изменений в логической схеме. Но, к сожалению, современные продукты SQL не поддерживают в необходимой мере обновления представлений. Поэтому набор допустимых физических схем в этих продуктах очень ограничен (причем совершенно излишне).

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

Логическое проектирование

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

■    Использование сочетаний столбцов и уменьшение количества зависимостей

В запросах поддержки принятия решений, а также в обновлениях, если они применимы, сочетания столбцов часто рассматриваются как единое целое. Имеется в виду, что к столбцам, входящим в состав подобных сочетаний, никогда не приходится обращаться по отдельности (наглядным примером  может служить адрес, ADDRESS). УСЛОВИМСЯ называть такие сочетания столбцов составными столбцами. Но с логической точки зрения подобные составные столбцы ведут себя так, как будто на самом деле они не  составные. Предположим, что СС — это составной столбец, а с — какой-либо иной столбец в той же таблице. Тогда зависимости между столбцом С и компонентом (компонентами) столбца СС сводятся к зависимостям между столбцом с и составным столбцом СС как единым целым. Более того, зависимости, включающие компоненты составного столбца СС и не включающие никакие другие столбцы, не имеют смысла и могут просто игнорироваться. В результате общее число зависимостей сокращается и логический проект становится проще, с меньшим количеством столбцов и, возможно, даже с меньшим числом таблиц.

■      Общие ограничения целостности

Как уже было описано выше, базы данных поддержки принятия решений в основном предназначены только для чтения, и ограничения целостности  проверяются только при загрузке (или обновлении) базы данных. Поэтому часто полагают, что нет никакого смысла объявлять ограничения целостности в их логической схеме. Но этот довод звучит неубедительно. Если база данных действительно предназначена только для чтения, такие ограничения на самом деле не могут быть нарушены. Но нельзя недооценивать семантическое значение этих ограничений. Как уже отмечалось в главе 9, ограничения служат для определения формального смысла таблиц и формального смысла всей базы данных в целом. Поэтому  определение ограничений предоставляет способ передачи пользователям  сведений о смысле данных, а это помогает им решать задачи формулирования запросов. Кроме того, объявление ограничений может  предоставлять крайне важную информацию для оптимизатора    (см.    обсуждение    семантической    оптимизации    в    главе    18). Примечание. В  некоторых программных продуктах объявление определенных ограничений  приводит  к  автоматическому  созданию  соответствующих  индексов и/или  других механизмов принудительного выбора путей доступа, что может существенно увеличить стоимость операций загрузки и пополнения базы данных. В свою очередь, для проектировщиков это может послужить поводом для отказа от объяапений ограничений. И снова повторим, что эта проблема возникает из-за путаницы между логическими и физическими аспектами  проектирования. Должна существовать возможность определить ограничения целостности декларативно, на логическом уровне, после чего отдельно  определить соответствующие механизмы принудительного выбора путей  доступа на физическом уровне. К сожалению, современные программные продукты не позволяют должным образом провести различия между логическим и физическим уровнями (более того, разработчики этих продуктов редко вообще признают семантическое значение ограничений).

■    Временные ключи

Оперативные базы данных обычно содержат только текущие данные. Базы данных поддержки принятия решений, наоборот, обычно содержат архивы  исторически накопленных данных и поэтому большая часть данных или даже все данные включают временной штамп,  или временную отметку. Ключи в таких базах данных часто содержат столбцы с временными отметками. Например, вновь обратимся к базе данных поставщиков и деталей. Предположим, что необходимо расширить ее таким образом, чтобы для каждой поставки был показан конкретный месяц (от 1 до 12), в который производилась поставка. В этом случае таблица поставок SP может выглядеть, как показано на рис. 22.1. Обратите внимание на то, что дополнительный столбец MID (идентификатор месяца) входит в состав ключа расширенной версии таблицы SP. Следует также отметить, что теперь запросы к данным из таблицы SP необходимо формулировать очень внимательно для того, чтобы доступ осуществлялся именно к тем данным, которые требуются, не больше и не меньше. Эти вопросы уже кратко рассматривались в разделе 22.2, а в главе 23 они описаны более подробно.

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

в каждой поставке зависит от того месяца, когда производилась эта поставка (на рис. 22.1 данные соответствуют этому ограничению). Тогда пересмотренная версия таблицы SP будет удовлетворять функциональной зависимости MID -> QTY и поэтому не будет находиться в пятой  нормальной форме и даже в третьей нормальной форме. Таким образом, возникает необходимость провести ее дальнейшую нормализацию, как  показано на рис. 22.2. К сожалению, проектировщики баз данных поддержки принятия решений редко задумываются над тем, что база данных должна учитывать такие зависимости. Дополнительные сведения об этом также приведены в главе 23.

Рис. 22.1. Пример таблицы SP, включающей поле идентификатора месяца

Рис. 22.2. Нормализованный аналог таблицы SP, представленной на рис. 22.1

Физическое проектирование

В разделе 22.2 было отмечено, что базы данных поддержки принятия решений, как правило, велики и в них широко применяются индексы, а также часто предусмотрены

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

Вначале рассмотрим подход к организации базы данных, называемый секционированием (известный также под названием фрагментации).  Секционирование (partitioning) представляет собой возможный подход к решению проблемы больших  баз данных. Каждая таблица делится на группу непересекающихся секций, или фрагментов, предназначенных для независимого физического хранения (см. обсуждение вопроса о фрагментации в главе 21). Такое секционирование позволяет существенно расширить возможности управления и доступа к рассматриваемой таблице. Обычно за каждой секцией закрепляются определенные выделенные (в той или иной степени) аппаратные ресурсы, например диск или процессор, вследствие чего конкуренция между секциями за такие ресурсы сводится к минимуму. Таблицы секционируются по горизонтали4  с помощью функции секционирования, которая использует значения выбранных столбцов, составляющих ключ секции, в качестве фактических параметров, а возвращает номер или адрес секции. Такие функции обычно поддерживают секционирование по диапазону (range partitioning), с помощью хэш-функции  (hash partitioning) и циклическое секционирование (round-robin partitioning), не считая других видов секционирования (см. аннотацию к [18.56] в главе 18).

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

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

■    Битовые индексы. Предположим, что в индексированной таблице т содержится п строк. Тогда битовый индекс для столбца с таблицы т будет содержать вектор из л битов для каждого возможного значения С и установленный бит будет соответст вовать строке R, если в строке R содержится соответствующее значение из столбца С. Такие индексы позволяют эффективно выполнять запросы, в которых исполь зуются множества значений, но их эффективность снижается, если эти множества становятся слишком велики. Обратите внимание на то, что несколько реляцион ных операций (соединение, объединение, сокращение по равенству и т.п.) могут быть выполнены исключительно с индексами с помощью простых логических операций (AND, OR, NOT) над битовыми векторами. Доступ к реальным данным во обще не происходит до тех пор, пока не потребуется получение окончательного

4 Хотявертикальноесекционированиетакжеможетиметьопределенныепреимущества,оноиспользуетсядовольноредко,поскольку большинствопрограммныхпродуктовегонеподдерживает.

результирующего набора. Операция обновления битовых индексов выполняется относительно неэффективно.

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

■     Мулътитабличные индексы (иногда они называются индексами соединении). По су ществу, элемент мультитабличного индекса содержит указатели на строки в не скольких таблицах, а не просто указатели на строки в одной таблице. Такие индек сы позволяют повысить производительность операций соединения и ускорить проверку ограничений целостности для нескольких таблиц (т.е. для базы данных), как описано в [22.33].

■     Логические индексы (более известные как индексы на основе логических выражений).

Логический индекс указывает, для каких строк определенной таблицы определен ное логическое выражение (включающее столбцы рассматриваемой таблицы) принимает значение TRUE. Такие индексы особенно полезны, если соответствую щее логическое выражение является общим компонентом условий операции со кращения.

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

В дополнение к сказанному следует отметить, что предусмотрены также различные виды смешанных,  или гибридных, индексов, представляющих собой сочетание перечисленных выше индексов. Смысл таких сочетаний трудно изложить в общих словах. Также предлагается множество специализированных видов индексов, таких как R-деревья, которые предназначены для обработки  пространственных данных. В настоящей книге не предпринимается попытка  решить такую трудоемкую задачу, как описание всех видов индексов; заинтересованные читатели могут обратиться к [26.37], где содержится исчерпывающее изложение этой темы.

Наконец, рассмотрим вопрос контролируемой избыточности. Контролируемая  избыточность — это важный инструмент сокращения количества операций ввода-вывода и минимизации конкурентного доступа к данным в базе. Как пояснялось в главе 1, избыточность  контролируема, если  она  управляется  СУБД и  скрыта от  пользователей. (Отметим, что по определению избыточность, которая должным образом контролируется на физическом уровне, остается невидимой на логическом уровне и поэтому не влияет на правильность данных на логическом уровне.) Существует два общих вида такой избыточности, которые описаны ниже.

■     Первый вид включает обслуживание в базе данных точных копий или реплик.

Примечание. Широко поддерживается также управление копированием,  которое может рассматриваться как более упрощенная форма репликации (см. следующий подраздел).

■  Второй вид включает обслуживание производных данных в дополнение к базовым данных. Наиболее часто используется в форме итоговых таблиц и/или расчетных (вычисленных или производных) столбцов.

Ниже каждая из этих возможностей рассматривается в отдельном подразделе.

Репликация

Основные понятия репликации были рассмотрены в разделах 21.3 и 21.4 главы 21 (см., в частности, подраздел "Распространение обновлений" в разделе 21.4). Здесь мы просто повторим несколько основных пунктов из этих разделов и приведем некоторые дополнительные замечания. Прежде всего, напомним, что репликация может быть синхронной или асинхронной, как описано ниже.

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

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

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

Рассмотрим кратко проблему согласованности (или, скорее,  несогласованности). Дело в том, что реплики могут становиться  несовместимыми в результате таких ситуаций, которых трудно (или даже невозможно) избежать и последствия которых трудно исправить. В частности, конфликты могут возникать по поводу того, в каком порядке должны применяться обновления. Например, предположим, что в результате выполнения транзакции А происходит вставка строки в реплику х, после чего транзакция в удаляет эту строку, а также допустим, что Y — реплика X. Если обновления распространяются на Y, но вводятся в реплику Y в обратном порядке

5 См. примечания на эту тему в предыдущей главе.

(например, из-за разных задержек при передаче), то транзакция в не находит в Y строку, подлежащую удалению, и не выполняет свое действие, после чего транзакция А вставляет эту строку! Суммарный эффект состоит в том, что реплика У содержит указанную строку, а реплика X — нет. В целом  задачи устранения конфликтных  ситуаций  и  обеспечения  согласованности  реплик  являются  весьма сложными. Дополнительные  сведения по этой теме выходят за рамки данной книги.

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

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

Производные данные

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

Примечание. Итоговые таблицы часто упоминаются под разными названиями; в частности,  они  именуются  итоговыми  таблицами  с  автоматизированным  расчетом  данных

(Automatic Summary Table — AST), материализованными таблицами запросов (Materialized

Query Table — MQT), снимками и материализованными представлениями. Последние два из этих терминов уже встречались раньше в этой книге (см. раздел 10.5 главы 10), где была высказана крайне резкая критика, в частности, такого термина, как материализованное представление. Но как бы то ни было, теперь это понятие стало темой большого раздела литературы, и в основной части этой литературы термин представление используется исключительно для обозначения  понятия материализованное представление (кроме всего прочего, см. [22.3] и [22.4]).

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

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

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

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

Примечание. Иногда дубликаты даже рассматриваются как полезное средство, особенно теми специалистами, которые имеют подготовку в области объектно-ориентированного

программирования (см. последний абзац в разделе 25.2 главы 25).   ■   Денормализация и связанные  с ней  действия. Руководствуясь необоснованным  стремлением  исключить

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

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

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

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

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

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

■     Множественные пути доступа. Проектировщики систем поддержки принятия ре шений и их пользователи часто ошибочно указывают на "множественность путей доступа" к некоторым необходимым им данным, подразумевая, что одни и те же данные могут быть получены с помощью нескольких разных реляционных выра жений. Иногда такие выражения действительно равносильны, как в случае, на пример, А JOIN   (В JOIN С) и (A JOIN В)   JOIN С (см. главу 18). Иногда они равносильны благодаря действию некоторого ограничения целостности (снова см. главу 18), но чаще всего на самом деле они оказываются отнюдь не равносиль ными! Для иллюстрации последнего случая предположим, что таблицы А, в и с та ковы: А, в имеют общий столбец КАВ, в и с — общий столбец квс, а А и с — об щий столбец КАС; тогда соединение таблиц А и в по столбцу КАВ, а затем соедине ние полученного результата с таблицей с по столбцу квс, безусловно, не будет од ним и тем же, что и соединение таблицА и с по столбцу КАС.

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

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

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

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии