Введение в системы БД (542480), страница 213
Текст из файла (страница 213)
В разделе 21.5 рассматриваются хранилища данных, магазины данных и "многомерные схемы". В разделе 21.6 обсуждаются оперативная аналитическая обработка (ОЬАР) и многомерные базы данных. Раздел 21.7 посвяшен разработке данных, а раздел 21.8 представляет собой резюме. 814 Часть К Дополнительные аспекты 21.2. Некоторые аспекты технологии поддержки принятия решений Базы данных поддержки принятия решений обладают специальными характеристиками, и главная из иих — база данньзх в основном (хотя и ие всегда) только читается.
Обновление обычно ограничено периодическими операциями загрузки или обновления. Из этих операций, в свою очередь, преобладает операция 1НЕЕНТ, операция НЕЪЕТЕ выполняется крайне редко, а операция НРВАТЕ не выполняется почти никогда. Замечание. Иногда операции обновления выполняются в некоторых подчиненных рабочих таблицах, но в обычных процессах поддержки принятия решений как таковых обновление самой базы данных почти никогда не используется. Приведенные ниже характеристики базы данных подлержки принятия решений также заслуживают внимания (мы еше возвратимся к этим характеристикам в разделе 2!.3 и конкретизируем их).
Отметим, что первые три из них — логические, а три оставшиеся— физические. ° Столбцы чаще всего используются в сочетаниях. ° Поддержкой целостности в общем случае не занимаются (подразумевается, что данные должны быть корректными, поскольку после загрузки они не корректировались). ° Ключи часто содержат временной компонент (глава 22). ° Базы данных обычно имеют большой объем, особенно в том случае (как это чаше всего бывает), когда данные деловых транзакций' накапливаются в течение достаточно продолжительного времени. ° В базе данных, как правило, интенсивно применяется индексация.
° База данных часто отличается различного рода контролируемой избыточностью (см. главу 1). Запросы поллержки принятия решений также имеют специфические особенности, и, в частности, обычно они довольно сложные. Ниже указано, в чем именно заключается сложность составляемых запросов. ° Сложность булевых выражений. Запросы поддержки принятия решений часто включают сложные выражения в предложении ННЕНЕ, Эти выражения сложно записывать, в них непросто разбираться и также трудно их выполнять. (В частности, классические оптимизаторы не всегда правильно обрабатывают подобные запросы, поскольку они проектируются для весьма ограниченного числа стратегий доступа.) Типичные проблемы вызывают запросы, в которых содержится значение времени.
Современные системы обычно не предоставляют удовлетворительной поддержки, например, для таких запросов, когда требуются строки с максимальным значением временной метки в заданный период времени (глава 22). Если в З Здесь и далее в двиной главе мы будем различать деловые транзакции (иапримвр, продажи продукции) и транзакции в таи смысле, который подразумевается в части!!' настоящей книги При этом для деловых транзакций всегда будет использоваться уточнение "деловые ", кроме твх случаев, когда эта очевидно из контекста.
815 Глава 21. Поддержка принятия решений запросах используются какие-нибудь соединения, то они очень быстро становятся чрезвычайно сложными. И вполне естественно, что в конечном итоге во всех этих случаях наблюдается низкая производительность. ° Сложность соединений. Для запросов в системах поддержки принятия решений часто требуется доступ ко многим видам информации, вследствие чего в правильно спроектированной, т.е. полностью нормализованной, базе данных прн выполнении этих запросов обычно осуществляется множество соединений. К сожалению, в технологических решениях для выполнения операций соединения никогда не предусматривалось обеспечение постоянно растущих потребностей запросов в системах поддержки принятия решенийэ.
Поэтому проектировшикн часто стремятся денориализовать базу данных с помощью "предварительных соединений" опредепенньзх таблиц. Однако, как уже отмечалось в главе 12, этот подход редко приводит к успеху, поскольку проектировщики в таких случаях сталкиваются со многими проблемами, которые потребуется предварительно решить. И кроме того, попытки избежать использования соединений могут привести к неэффективному применению реляционных операций, поскольку при этом выполнение выборки и соединения огромных объемов данных просто переносится из СУБД в приложение. ° Сложность функций. В запросах систем поддержки принятия решений часто используются статистические и другие математические функции. Но лишь немногие продукты их поддерживают, Поэтому часто возникает необходимость в разбиении запроса на последовательность меньших запросов, которые затем выполняются поочередно с пользовательскими процедурами для вычисления требуемых функций.
В результате такого подхода, к сожалению, может потребоваться извлечение больших объемов данных, не говоря уже о том, что сам запрос становится значительно сложнее как для написания, так и для понимания. ° Аналитическая сложность. Деловые запросы редко можно сформулировать в виде одного простого запроса. Чрезмерно сложные запросы представляют значительные трулности не только лля пользователей. Ограничения, свойственные конкретной реализации языка ЯОЬ, могут не позволить системе выполнять обработку подобных запросов. Олним из путей упрощения подобных запросов является нх разбиение на ряд меньших запросов с сохранением результатов во вспомогательных таблицах.
Указанные выше особенности как баз данных систем поддержки принятия решений, так и выполняемых в них запросов являются причиной того, что акцент в этом случае переносится на проектирование с точки зрения повышения производительности, особенно — производительности пакетного добавления данных н произвольного извлечения данных. Однако, на иаш взгляд (который подробно излагается следуюшем разделе), та- з - Автор этой главы (Мак-Говернд работавший над систеиой поддержки решений в (981 году, в результате собственных наблюдений выяснил, что дэя соединения трех таблиц да.же средних размеров вполне лзожет потребоваться лзного часов. Соединение же от четырех до изести таблиц вообще обходится слишкаи дорого.
В современных каипьютерал соединение от шести до десяти очень бал ыиих таблиц — обычное дело, и техн ологиеи это также, как правило, предусмотрено. Однако достаточно просто (и в этом нет ничего необычного! генерировать запросы, при выполнении которых потребуется соединить столько таблиц, сколько технологически невозиожно обработать. Запрос на соединение более двенадцати таблиц, скорее, похолс на авантюру, но необходилзость выполнения подобных запросов встречается довольно часто. 81б Часть К Дополнительные аспекты кое состояние дел должно влиять на физическое проектирование, а не на логическое. К сожалению, как уже отмечалось в разделе 21.1, разработчики и пользователи систем поддержки принятия решений часто делают ошибку, неверно различая логические и физические аспекты проектированияз.
Фактически они часто вовсе отказываются от создания логического проекта системы. Вследствие этого, столкнувшись с перечисленными выше сложностями, они оказываются неподготовленными к ним, и это чаше всего приводит к непреодолимым трулностям при попытках сохранить равновесие между корректностью, возможностью сопровождения, производительностью, возможностью расширения, эффективностью и практичностью. 21.3. Проектирование базы данных поддержки принятия решений Как утверждалось ранее, в частности во введении к части Ш, по нашему мнению, проект базы данных всегда должен быть выполнен на двух уровнях: логическом и физическом.
1. Прежде всего должен быть выполнен логический проект. На этом уровне основное внимание уделяется реляционной корректности. Таблицы должны представлять правильные отношения, гарантируя таким образом, что реляционные операции будут выполняться так, как им надлежит выполняться, и не будет никаких непредсказуемых результатов. Далее должны быть описаны домены (типы), на основе доменов определены столбцы н указаны зависимости между столбцами (функциональные н др.). На основании этих данных может быть выполнена нормализация и определены ограничения целостности.
2. Затем созлается физический проект, который должен быть производным от логического проекта. На этом уровне, конечно, основное внимание уделяется эффективности хранения данных и производительности. В принципе, допустимо любое расположение данных при условии, что между логической и физической схемами имеется сохраняющее информацию преобразование, поддающееся выражению с помощью реляционной алгебры (2.51 Отметим, в частности, что из наличия такого преобразования следует, что существуют реляционные представления физической схемы, которые отображают ее подобно логической схеме, и наоборот. Безусловно, логическая схема может впоследствии изменяться, например с целью включения новых видов данных и новых или только что обнаруженных зависимостей. Внесенные изменения, естественно, потребуют также соответствующих изменений в физической схеме. Но этот вопрос нас здесь не беспокоит.
Нас больше волнует то, что физическая схема может измениться, в то время как логическая схема будет оставаться прежней. Например, предположим, что операция соединения таблиц ЯР (Поставки) и Р (Детали) в значительной степени преобладает по сравнению с другими схемами доступа к данным. Тогда у нас мог бы возникнуть соблазн "предварительно соединить" таблицы З Особенно виновны в этим гпециачигты па крапилин)аи данных и оперативной аналитической обработке (ОьАР). Они часто утверждают, чта реляционный проект просто "непригадви" для систем поддержки принятия решений, а реляцианиая модель нг апгюабиа ааггпечить выборку данных и ее нужна абаити. Такие аргументы почти всегда агнааываютги на игвериам понимании различий между собственно реляционной моделью и ее физическим пргдставлгиием. 817 Глава 21. Поддержка принятия решений ЯР и Р на физическом уровне, сократив таким образом количество операций ввода- вывода и расходы на соединения этих таблиц.
Но логическая схема должна оставаться неизменной, если достигнута физическая независимость данных. (Конечно, оптимизатор запросов должен знать о существовании хранимого "предварительного соединения" и действовать соответственно, чтобы получить желаемое повышение производительности.) Кроме того, если модель доступа затем изменится на преобладающий доступ к отдельным таблицам вместо их соединения, должна существовать возможность вновь изменить физическую схему, чтобы физически разъединить таблицы БР и Р, опять же, без какого-либо влияния на логический уровень.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
