Принцип гласящий что время есть ключевой компонент склада данных это

Образовательный блог — всё для учебы

Понятие Склада Данных (Хранилище) получило активное хождение после 90-ого года и до сих пор расценивается как перспективное динамичное направление в проектировании информационных систем поддержки принятия решения. Одно из определений склада данных заключается в том, что это специальная база данных где в хронологическом порядке накапливаются все данные деятельности предприятия (не операционная). Назначения этих данных служить основой для получения справочной аналитической и обобщающей информацией. Автор концепции хранилища данных Imond.

В 91 году фирма IBM первая предложила архитектуру информационного склада. Склад данных естественно ориентирован на определенную предметную область. Очень часто на складах хранится не все полученная информация, а обобщенная информация. По сути дела данные постепенно поступая на склад получаются статус неизменной информации. Основные компоненты склада данных следящие:
— Средство накопление слада
Программа, которая из ОЛТП из информационной системы подготавливает, обрабатывает и записывает в ОЛАП системы.

— Сама база данных
Чаще всего реляционная БД, хотя сейчас многие производители СУБД (МS) сделал ОЛАП систему… Оракал делал… Такого рода базы данных как правило работают при пакетной загрузке, в том смысле год закончился – и всю информацию за год записывают на склад

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

Основные принципы организации складов данных:

1) Предметная ориентация
Например: для магазина торгующего аудио видео техникой интерес могут представлять такие области как: клиенты, кассеты, CD-диски и тд.

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

3) Постоянство данных
Как правило Хранилища данных не включают средств для изменения данных. Пакетная загрузка, пакетная обработка.

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

Важным моментом надо отметить тот факт, что такого рода базы данных ОЛАП системы на пустом месте не создаются, то есть для того чтобы ее создать нужно уже какую-то операционную базу данных уже иметь. Туда не заносят данные каждый день.

Несколько слов как происходит обобщение данных. Для операционных баз данных, с которыми клиент работает ежеминутно, конечно необходим максимальный уровень детализации данных о каждом клиенте, поставщике, компакт диске и т.д. О пользователям такого рода систем, конечно, подробный список всех клиентов или отчет о товаре не нужен. Менеджеру аналитику чаще всего нужны усредненный данные… за месяц, за квартал и т.д. Данные по разным регионам, чтобы знать чего куда везти (В деревню – валенки). Таким образом важным моментом такого рода систем является обобщение информации (данных). Информация – это все что мы видим, слышим и так далее. По ГОСТУ информация в цифровом – виде данные. Конечно формально говоря, вот это обобщение информации можно было делать сразу в операционной базе данных, но как правило это не делают – это дополнительная нагрузка. Пример: идет покупатель за покупателем, один больше покупает, другой меньше товаров.

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

Источник

Хранилища данных

Изучив материал настоящей лекции, вы будете:

Концепция систем складирования данных

Введение

Информационная технология складирования данных (data warehousing) родилась в недрах компании IBM [1] и была окончательно сформулирована Б. Инмоном и Р. Кимбаллом в 90-х годах прошлого столетия [2,3] как метод решения информационно-аналитических задач в области принятия и поддержки решений. Возникнув на стыке технологии баз данных (БД), систем поддержки принятия решений ( СППР — DSS) и компьютерного анализа данных, в дальнейшем концепция складирования данных претерпела эволюцию, поскольку оказалась пригодной для широкого круга приложений в бизнесе, науке и технологии.

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

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

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

Хранилище данных (ХД — data warehouse) является местом складирования собираемых в системе данных и информационным источником для решения задач анализа данных и принятия решений. Как правило, объем информации в ХД является достаточно большим. Упрощенно можно сказать, что хранилище данных управляет данными, которые были собраны как из операционных систем организации (OLTP-систем — On-Line Trasactions Processing), так и из внешних источников данных, и которые длительный период времени хранятся в системе. Более точное определение будет дано позже, после обсуждения истории создания концепции складирования данных.

Одной из главных целей создания систем складирования данных является их ориентация на анализ накопленных данных, т.е. структуризация данных в ХД должна быть выполнена таким образом, чтобы данные эффективно использовались в аналитических приложениях ( analytical applications ).

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

Концепция баз данных (БД) как метод представления и накопления данных в электронном виде сформировалась к середине 60-х годов прошлого века в фирме IBM. В 1969 году была создана первая СУБД для управления и манипулирования данными как самостоятельными информационными объектами. В 1970 году была предложена реляционная модель данных для БД [4], и на ее основе начали создаваться популярные ныне реляционные СУБД. В рамках реляционной модели с единых позиций были решены многие проблемы операционной ( транзакционной) обработки данных.

С середины 80-х годов прошлого столетия стали интенсивно накапливаться электронные информационные массивы данных организаций, корпораций, научно-исследовательских учреждений. Так, в начале 90-х годов прошлого века только в области химических дисциплин было зарегистрировано более 7000 библиографических, фактографических и смешанных баз данных, ведущие мировые корпорации создали огромные электронные массивы конструкторской документации и документации по управлению производством. В это же время возникло четкое понимание, что сбор данных в электронном виде – не самоцель, накопленные информационные массивы могут быть полезны. Первыми осознали этот факт в области управления бизнесом и производством. В накопленных данных организации находится «информационный снимок» хронологии ее поведения на рынке. Анализ истории административно-хозяйственной деятельности организации позволил существенно увеличить эффективность ее управления, эффективно организовать взаимоотношения с клиентами, производство и сбыт.

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

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

Предпосылки создания концепции складирования данных

Автоматизированная информационная система (ИС) с БД, будучи средством удовлетворения потребностей пользователей в информации как производственном ресурсе, работает с потоками информации, выраженными в потоках данных и операциях с ними. Как было указано выше, основной акцент на ранних стадиях эксплуатации ИС с БД строился на операционной концепции работы с данными. ИС, грубо говоря, должна была быстро и адекватно «переварить» поток данных для решения поставленных перед ней задач с помощью унифицированного набора операций манипулирования данными. Обработка данных сводилась к операциям вставки, удаления и обновления. Это было зафиксировано первоначально концепцией БД КОДАСИЛ [7].

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

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

Фундаментальные требования к разработке операционных систем обработки данных и систем анализа данных различны: операционным системам нужна производительность, в то время как системам анализа данных нужны гибкость и широкие возможности для получения результата. Это противоречие в целевой направленности двух классов систем обработки данных явилось одной из основных предпосылок разработки концепции складирования данных ( рис. 1.3).

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

Системы, доставшиеся в наследство

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

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

Перенос данных из централизованного ВЦ на рабочий стол пользователя

Второй причиной стал персональный компьютер, который позволил перенести данные из централизованного вычислительного центра на рабочий стол пользователя (в частности бизнес-аналитика).

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

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

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

Системы поддержки и принятия решений и управленческие информационные системы

Развитие технологий

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

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

Структурные изменения в бизнесе

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

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

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

Появление стандартов для программного обеспечения бизнеса

Еще одним важным фактором, который повлиял на развитие ХД, явилось появление специализированных поставщиков решений в автоматизации бизнеса. Фирмы-разработчики ПО SAP AG, Baan, Oracle, Microsoft, IBM и др. предлагают быстро адаптируемые к бизнес-процессам программные продукты для управления бизнесом. Разработка комплексного ПО для управления бизнесом привела к интенсификации процессов стандартизации бизнеса и стандартизации программного обеспечения. Информация в ХД поступает в унифицированном виде из всех ИС управления бизнесом, а не только из систем, доставшихся по наследству. Следует также отметить тенденцию последних лет в разработке ПО данного класса приложений — обеспечение возможности собирать информацию в ХД из данных любых внешних источников (например продукты компании SAS).

Требования пользователей

Один из наиболее важных результатов массивной инвестиции в технологию и создание высокопроизводительных ПК привел к созданию методов анализа, основанного на здравом смысле (technology-savvy business analyst ). Даже если технология здравого смысла конечного пользователя не всегда выгодна для многих проектов, тенденция ее применения привела к созданию более сложных технологий анализа для сегодняшнего бизнеса. Однако именно на технологии здравого смысла была продемонстрирована выгода использования хранилищ данных и развития логических и физических моделей.

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

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

Источник

Глава 4. Склады данных

Практические выводы

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

Данные, поступившие на склад, приобретают статус постоянной информации, т. е. вносимые изменения носят характер «пополнения» (путем регулярных плановых выборок из операционных баз), а не произвольных поэлементных модификаций, как в операционных базах данных.

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

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

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

Что дает эта технология?

4.1. Введение

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

4.2. Принципы построения складов данных

«Одной из наиболее значительных тенденций 90-х будет развитие и внедрение складов данных и соответствующих методов обработки информации. С появлением складов данных изменятся некоторые устоявшиеся представления об управлении данными.»

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

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

Ниже перечислены четыре основополагающих для организации складов данных принципа.

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

Нетрудно провести аналогию между предметными областями склада данных и классами объектов в объектно-ориентированных базах данных. Очевидно, что методы проектирования и моделирования, применяемые в объектно-ориентированных СУБД, могут оказаться полезными и при проектировании предметных областей складов данных.

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

4.3. Множественность носителей информации

Рассмотрим простую среду склада данных, предназначенного, например, для поддержки приложений небольшого магазина, торгующего видео- и музыкальными записями. Исходя из посылки «память ничего не стоит» в условиях быстрого распространения дисков большой емкости на ПК, соединенных локальными сетями, трудно предположить, что у нас когда-либо в обозримом будущем возникнут проблемы с нехваткой памяти.

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

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

4.4. Обобщение данных

Примеры на рис. 4-1 и 4-2 представляют концепцию склада данных в слишком упрощенном виде. «Мгновенные снимки» операционных данных извлекаются из баз данных или других информационных источников и поступают в склад данных в интегрированном виде. Однако склад данных не поддерживает тот же высокий уровень гранулярности информации, который характерен для баз данных.

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

Пользователей систем DSS или EIS, напротив, вряд ли будет интересовать список всех клиентов или полный отчет о прокате или продажах каждого CD. Менеджеру-аналитику высокого ранга не понадобится даже месячный отчет с подобной информацией.

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

В складе данных, разумеется, можно поддерживать несколько уровней гранулярности (т. е. более или менее обобщенную информацию ), что очень желательно для проведения анализа «вглубь» (drill-down analysis). Анализ «вглубь» полезен в тех случаях, когда пользователь обнаруживает интересное для него явление и стремится докопаться до его причин, истоков и подробностей. На рис. 4-5 показаны структуры, ориентированные на поддержку типичного анализа «вглубь». Если в складе данных поддерживаются связи от каждого уровня обобщения к уровням, «питающим» его, то соответствующие приложения могут производить обход данных по этим ссылкам.

4.5. Распределенные склады данных

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

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

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

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

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

4.6. Переписывая историю

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

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

2. Поскольку склад данных (как уже говорилось в разд 4.4) ориентирован на хранение обобщенной информации, то в нем может не поддерживаться уровень гранулярности, необходимый для выполнения требуемых изменений. Можно было бы изменять обобщенную информацию (например, увеличить сумму месячного дохода магазина в Туксоне на 10%), однако аналитику для проведения какого-то исследования, возможно, потребуется изменить сумму дохода только в определенные дни месяца. Если в складе данных отсутствует соответствующий уровень детализации, то проведение подобного анализа может оказаться затруднительным.

Полное использование преимуществ складов данных невозможно без средств анализа «что если». Для достижения этой цели структуры и механизмы складов данных должны быть дополнены рядом новых возможностей, например такими базовыми средствами, как поддержка транзакций с модификацией данных.

4.7. Склады данных и другие технологии информационного управления

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

4.7.1. Приложения и базы данных клиент-сервер

На рис. 4-8 приложение EIS, написанное на языке Xbase (см. гл. 14, где рассматривается этот язык), осуществляет доступ к централизованному SQL-складу данных посредством прикладного программного интерфейса ODBC, который мы обсуждали в гл. 3. В такой среде довольно легко реализовать простейшую модель клиент-сервер, где один сервер обслуживает несколько клиентов.

На рис. 4-9 представлен более сложный вариант архитектуры клиент-сервер. Доступ к логически централизованному складу данных, распределенному на множестве платформ (см. разд. 4.5), осуществляется так же, как и в примере на рис. 4-8. Однако внутри склада данных для доступа к его распределенным компонентам (фрагментам) применяется комбинация интерфейсов IDAPI и DRDA API. В таком случае приложение, выполняющееся над складом данных, выступает в двоякой роли: как сервер для комплекса приложений EIS и как клиент, запрашивающий информацию у других серверов склада данных.

4.7.2. Активные базы данных

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

Разумеется, оправданной может оказаться комбинация двух типов окружений, изображенных на рис. 4-10 и 4-11 (активные базы данных как на стороне склада, так и на стороне его источника). Кроме того, выполнение хранимой процедуры склада данных может быть инициировано и приложениями EIS/DSS.

Активные базы данных рассматриваются в гл. 16.

4.7.3. Гипертекст

4.7.4. Хронологические базы данных

4.8. Электронные библиотеки и информационные магистрали

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

4.9. Заключение

Перспективы

Краткосрочные

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

Долгосрочные

Внедрение современных технологий баз данных в среде складов данных: механизмы активных баз данных, активные репозитории, живые связи и т. д. Средства анализа «что если».
Более тесная связь между складами данных и операционными базами данных.
Применение технологий складов данных в реализации электронных библиотек, информационных супермагистралей и т. п.

Литература

Ссылки

*) Глава из книги «Strategic Database Tecnology: Management For The Year 2000», выходящей в издательстве «Финансы и статистика» в 1998 г. (c) Morgan Kaufman Publishers, Inc (c) «Финансы и статистика»

Поделитесь материалом с коллегами и друзьями

Источник