При разработке хранилища данных, возникают и должны быть решены следующие вопросы:
1) какие данные должны быть помещенный в хранилища
2) Как найти и извлечь эти данные
3) Как обеспечить корректность данных.

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

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

Вторая часть связанная со сбором – это периодическое пополнение. Здесь надо решить как будет пополняться База данных ежемесячно, ежеквартально и т.д. Решается это как правило с использованием механизмом событий, тут в ручную никто конечно ничего не делает. Составляется программа, которая по каким то события автоматически это дело делает. Попадание этих данных на склад, это не самое простой процесс, поскольку данные надо обустроить – обеспечить регулярность попадания, попадание в требуемом виде. Например: город Москва должен быть написан идентично (кто-то напишет маленькими буквами, кто-то большими). Проблема исключения дубликата, такие сведения могут быть возможны. Вторая проблема при этом – восстановление пропущенных данных. Например: для мед учреждение характерно и в силу той или иной болезни, врач заносит данные не все. Бывает анализ мочи – снимают показания не для всех параметров, а для определенной болезни. Сняли 5 данных … а в таблице 20 показателей. Восстановление пропущенных данных очень большая проблема, потому как не ясно решить. Потому как что куда поставить. С одной стороны это мешает обобщению отсутствие данных, потому как пусто нужно просуммировать с какими-то конкретными данными и сразу показатели по каким то колонкам ухудшаются. А с другой стороны написать фиктивно, что-то не соответствующие действительности, для одной болезни показатель важен, а для другой нет. (ой дальше его понесло). Удаление нежелательных символов, приведение к единому формату. Таким образом здесь при сборе данных очень важно разрабатывать сложную систему, которая начинает приводить к общему виду. Это не сложная, но кропотливая и долгая работа учитывать все нюансы. К примеру: продавцы в разных местах могут одну и туже кассету назвать по разному.

Витрины данных

Концепция витрин данных была предложена в 1992 году. Появление концепции витрин данных связано с тем что оказалось, не смотря на то что хранилище данных вещь хорошая, но разработка ее и внедрение происходит в течение нескольких лет. И это сказывается на затратах предприятиях, которые долго не окупаются. Из-за того что часто информационная структура компаний бывает сложна и запутана – сделать хранилище данных не представляется сделать одним махом. Вторых проблема как уже было сказано с инвестициями. В третьих очень часто существующие операционные системы ОЛТП приходится тоже переделывать, чтобы они тоже хранили или запоминали те данные, которые нужны для кубов. Важный пункт то, что существующие технологии в принятиях решений трудно поддаются модификации и изменению и поэтому под них приходиться подстраиваться, то есть подстраивать свои данные и под существующие технологии. Поэтому появление витрин данных была попыткой смягчить требования к хранилищам данных. По сути под витриной данных понимают специализированные хранилища, обслуживающие одно из направлений деятельности. К примеру: маркетинг, учет запасов и ст.д. Из всего хранилища данных выделяют направления и они автоматизируются. Как правило в 1 очередь берутся те процессы которые легко автоматизируются, хорошо изучены, не так сложны и внедрение этих витрин данных позволяет уже на маленьких примерах быстро получить окупаемость. Таким образом очень часто разработка хранилища данных и витрин данных идет параллельно, то есть в перспективе нужно хранилище данных, но походу разрабатываются витрины, которые начинают давать отдачу, с другой стороны позволяют разработчикам показать заказчикам, что эффект есть. Также как и для хранилищ данных стандартом является структура звезды и таблица фактов.

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

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

На сегодня имеется достаточно много промышленных систем, которые подходят под понятие витрин данных. Прежде всего фирма информатика выпустила продукт PowerMarcSuit. Далее Stgentehnology выпустила DataMapSollution. Oracale выпустила продукт DataMapSuit. В 94 году было предложено объединить концепции витрин данных и хранилища данных и использовать хранилища для витрин данных. Поскольку программное обеспечение для анализа хранилищ данных составляется очень долго, а само хранилище сделать трудно, собрать данные соединить в базу не так сложно, трудно приделать ей программное обеспечение, которое анализ бы делала, поэтому целью объединения было то, чтобы сами витрины данных основывались бы на данных, которые хранятся в хранилищах. Ну и было предложено так называемая многоуровневая архитектура из трех уровней.

Первый уровень общекорпоративной базы данных на основе распределенной СУБД.

Второй уровень базы данных подразделений. Как правило на основе десктоп СУБД. Здесь храниться агрегированные данные, то есть реляционные базы данных хранят операционные данные, а агрегированные данные отбрасываются на 2 уровень, где можно использовать Десктоп СУБД.

И третий уровень это конкретные места пользователей-аналитиков. Те пользователи, которые на основе витрин данных делают какие-то выводы.

Комментарии запрещены.