SAFE/DW (Data Warehouse) - методология разработки  хранилищ данных которая предлагает  ряд подходов, позволяющих ускорить  процесс построения ХД. В частности,  в рамках исследовательской стадии  проекта она требует определить  бизнес-цели, информационные запросы, определить критические для успеха факторы, разработать предварительную бизнес-модель. В рамках создания бизнес-модели требуется идентифицировать потоки данных, выявить относительную ценность данных, смакетировать потоки данных в логическую структуру объектов. 

2 глава  Исследование методов организации структуры данных для аналитических систем. 

2.1 СУБД для аналитических  систем

      2.1.1 РСУБД

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

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

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

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

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

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

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

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

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

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

      Другим  подходом к повышению производительности является вертикальная фрагментация данных (она используется в решении фирмы  Sybase). Предположим, что у нас имеется таблица из 10 000 000 строк, каждая строка состоит из 30 полей (колонок), по 10 символов (байт) каждое. Абстрагируясь от вопросов эффективности или неэффективности хранения данных в конкретной реализации РСУБД, предположим, что объем результирующей БД равен объему исходных данных. В этом случае мы получим БД размером в 3 гигабайта.

      В традиционных реализациях РСУБД  данные хранятся построчно, и при  последовательном просмотре вне  зависимости от того, значения из скольких колонок таблицы требуются для  формирования ответа на запрос, будут считаны все 3 гигабайта данных. Но в аналитических запросах крайне редко возникает необходимость работы одновременно со всеми колонками таблицы. Именно на этом предположении и основывается механизм вертикальной фрагментации, при использовании которого данные хранятся не построчно, а по столбцам. Таким образом, каждый столбец представляет собой независимый раздел данных и при запросах на чтение может обрабатываться независимо. И если в нашем примере для формирования ответа на запрос потребуются значения из трех столбцов таблицы, нужно будет считать только 300 мегабайт, а не 3 гигабайта данных.

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

      Оптимизаторы  обработки запросов со схемой звезда.

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

      Покажем это на примере. Такой способ оптимизации  дает эффект только тогда, когда промежуточная  таблица умещается в оперативной  памяти. Но это не всегда так. Если запрос ссылается на 10 справочных таблиц, в  каждой из которых всего 10 строк длиной в 40 символов, в результате декартова произведения мы получим промежуточную таблицу в 10 млрд. строк. А объем оперативной памяти, необходимый для размещения такой таблицы, составит 400 гигабайт. И это без учета памяти для операционной системы, системных программ СУБД и буфера для просмотра теперь уже ставшей относительно маленькой фактологической таблицы.

      Bitmap-индексы

      Бесполезны  при малом числе различных  значений в индексируемой колонке. Предположим, что индексируется  поле "Пол Сотрудника". Здесь мы имеем всего два значения: Мужской/Женский. И если данные не были заранее упорядочены по этому полю, и оно используется в качестве критерия выборки, скорее всего, придется считать всю таблицу. Это связано с тем, что на физическом уровне считывается не отдельная строка, а блок, в котором размещены значения нескольких строк, и вероятность того, что в каждом блоке записаны только строки, относящиеся к мужскому или женскому полу, настолько невелика, что применение Bitmap-индексов только замедлит выполнение запроса.

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

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

      Горизонтальное  разбиение данных

      Разбиение таблицы может производиться  только в соответствии со значениями данных одной колонки таблицы.

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

      Вертикальное  разбиение данных

      Эффективно  только в том случае, если при  выполнении запроса требуется просмотр всего нескольких колонок таблицы, и чем меньше соотношение - "Число колонок в таблице/Число колонок, на которые есть ссылки в запросе", тем менее эффективным оказывается данный метод.

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

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