|
и чтение (доступ). Это и определяет специфику проектирования структуры базы данных для DW. Если при создании OLTP-систем разработчики должны учитывать такие моменты, как откаты транзакций после сбоя сервера, борьба с взаимными блокировками процессов (deadlocks), сохранение целостности данных, то для DW данные проблемы не столь актуальны перед разработчиками стоят другие задачи, связанные, например, с обеспечением высокой скорости доступа к данным. Поскольку информация в DW загружается из OLTP-систем, возникает вопрос, не ведет ли это к чрезмерной избыточности данных? Нет, утверждает Билл йнмон. Па самом деле избыточность минимальна (около !%!), что объясняется следующими причинами: . при загрузке информации из OLTP-систем в DW данные фильтруются. Многие из них вообще не попадают в DW, поскольку лишены смысла с точки зрения использования в системах поддержки принятия решений; • информация в OLTP-системах носит, как правило, оперативный характер, и данные, потеряв актуальность, удаляются. В DW, напротив, хранится историческая информация, и с этой точки зрения перекрытие содержимого DW данными OLTPсистем оказывается весьма незначительным; • в DW хранится некая итоговая информация, которая в базах данных OLTP-систем вообще отсутствует; • во время загрузки в DW записи сортируются, очищаются от ненужной информации и приводят к единому формату. После такой обработки это уже совсем другие данные. Остановимся на некоторых проблемах реализации хранилища данных: • Неоднородность программной среды • Распределенный характер организации • Повышенные фебоваиия к безопасности данных • Необходимость наличия многоуровневых справочников метаданных |
В OLTP-системах информация часто модифицируется как результат выполнения каких-либо транзакций. Временная инвариантность данных в DW достигается за счет введения полей с атрибутом "время" (день, неделя, месяц) в ключи таблиц. В результате записи в таблицах DW никогда не изменяются, представляя собой снимки данных, сделанные в определенные отрезки времени. В DW содержатся как бы моментальные снимки данных. Каждый элемент в своем ключе явно или косвенно хранит временной параметр, например день, месяц или год. В OLTP-системах записи могут регулярно добавляться, удаляться и редактироваться. В DW-системах, как следует из требования временной инвариантности, однажды загруженные данные теоретически никогда не меняются. По отношению к ним возможны только две операции: начальная загрузка и чтение (доступ). Это и определяет специфику проектирования структуры базы данных для DW. Если при создании OLTP-систем разработчики должны учитывать такие моменты, как откаты транзакций после сбоя сервера, борьба с взаимными блокировками процессов (deadlocks), сохранение целостности данных, то для DW данные проблемы не столь актуальны перед разработчиками стоят другие задачи, связанные, например, с обеспечением высокой скорости доступа к данным, Поскольку информация в DW загружается из OLTP-систем, возникает вопрос, не ведет ли это к чрезмерной избыточности данных? Нет, утверждает Билл Инмон. На самом деле избыточность минимальна (около 1%!), что объясняется следующими причинами: • при загрузке информации из OLTP-систем в DW данные фильтруются. Многие из них вообще не попадают в DW, поскольку лишены смысла с точки зрения использования в системах поддержки принятия решений; • информация в OLTP-системах носит, как правило, оперативный характер, и данные, потеряв актуальность, удаляются, В DW, напротив, хранится историческая информация, и с этой точки зрения перекрытие со43 держимого DW данными OLTPсистем оказывается весьма незначительным; • в DW хранится некая итоговая информация, которая в базах данных OLTP-систем вообще отсутствует; • во время загрузки в DW записи сортируются, очищаются от ненужной информации и приводят к единому формату. После такой обработки это уже совсем другие данные. Остановимся на некоторых проблемах реализации хранилища данных: • Неоднородность программной среды • Распределенный характер организации • Повышенные требования к безопасности данных • Необходимость наличия многоуровневых справочников метаданных • Потребность в эффективном хранении и обработке очень больших объемов информации Хранилище данных практически никогда не создается на пустом месте. Почти всегда конечное решение будет разнородным, т.е. в нем будут использоваться автономно разработанные программные средства. Прежде всего это касается формирования интегрированного согласованного набора данных, которые могут поступать из разнородных баз данных, электронных архивов, публичных и коммерческих электронных каталогов, справочников, статистических сборников. При построении хранилища данных приходится решать задачу построения единой, согласованно функционирующей информационной системы на основе неоднородных программных средств и решений. При выборе средств реализации хранилища данных приходится учитывать множество факторов, включающих уровень совместимости различных программных компонентов, легкость их освоения и использования, эффективность функционирования и т.д. В концепции хранилища данных предопределено то, что операционная аналитическая обработка может выполняться в любом узле сети независимо от места расположения основного хранилища. Хотя при аналитической обра44 |