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

Удовлетворить одновременно и операционные, и информационные потребности компании (к последним относят обычно системы поддержки принятия решений [DSS] и информационные системы руководителя [EIS]) - непростая задача. Базы данных, ориентированные на оперативную обработку, зачастую плохо справляются с задачами информационного анализа; попытки возложить на них эту деятельность приводят, как правило, к недопустимому снижению производительности и пропускной способности на оперативной обработке.

Существует мнение, что в 90-е годы в сфере информационного управления неуклонно будет возрастать роль складов данных. Различные степени обобщения данных, поддержка исторической информации, консолидация множества источников данных и др. - вот те средства, которые могут помочь в решении проблем снабжения данными информационных приложений. Еще более важно то, что тенденции в развитии складов данных, особенно в области распределения данных в приложениях DSS/EIS, которые могут осуществлять доступ к множеству "мини-складов данных", окажут существенное влияние на характер применения этой технологии в ближайшие несколько лет.

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

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

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

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

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

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

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

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

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

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

4.1. Введение

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

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

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

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

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

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

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

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

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

клиенты;
видеокассеты;
CD-диски и аудиокассеты;
сотрудники;
поставщики.

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

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

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

4) Хронологизм данных. Благодаря средствам интеграции, склад данных - это нечто большее, чем просто изощренная последовательность "моментальных снимков"; она всегда имеет определенный хронологический, временной аспект, присущий ее содержимому. В гл. 15 мы рассмотрим хронологические базы данных как еще одну новую область информационного управления. Фундаментальный принцип хронологических баз данных, гласящий, что время есть ключевой компонент базы данных и ее содержимого, в той же мере можно отнести и к складам данных.

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

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

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

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

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

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

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

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

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

Ключ к эффективности приложений склада данных - это обобщение информации. Возможно, приложения DSS или EIS могли бы самостоятельно проводить обобщение подробной информации, выбираемой из операционных баз данных или из складов данных (где она поддерживается с той же высокой степенью гранулярности). Но это абсолютно непрактично, по крайней мере, по одной из двух причин: (1) дополнительная нагрузка на операционную базу данных, создаваемая в результате выполнения многочисленных выборок и обобщений данных, приведет к снижению производительности на текущих операциях; (2) неоправданное увеличение объема необходимой памяти в складе данных для хранения элементов данных, которые никогда не используются индивидуально.

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

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

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

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

Интерес к складам данных значительно усилился в 1991 г., когда IBM объявила свою архитектуру Информационного склада (Information Warehouse), которая, по замыслу, должна была стать оболочкой для распределенных неоднородных баз данных. Информационный склад должен "...предоставить инструменты и средства управления данными и выдачи полной, точной и актуальной деловой информации для уполномоченных лиц с целью эффективной поддержки принятия решений" .

В представлении IBM Информационный склад - это среда, в которой применяются разнообразные виды ПО промежуточного слоя, включая DRDA (Distributed Relational Database Architecture, см. гл. 3), обеспечивающая все усложняющиеся требования распределенных приложений.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Переход к базам данных клиент-сервер - относительно небольшой скачок в развитии складов данных. На рис. 4-8 и 4-9 показаны две альтернативные архитектуры складов данных, основанные на современной модели клиент-сервер.

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

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

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

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

С массовым распространением активных баз данных видится несколько способов применения таких средств в среде склада данных. Как показано на рис. 4-10, в активной базе данных, используемой как источник данных для склада, активные механизмы могут вызывать автоматическую передачу очередных "моментальных снимков" в склад. В такой модели выгрузка данных в склад может быть реализована как плановое действие в базе данных - источнике, не требующее инициативы со стороны какого-либо пользователя или приложения.

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

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

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

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

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

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

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

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

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

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

В этой главе мы рассмотрели основные принципы построения и важнейшие тенденции развития складов данных. Как мы упоминали, термин "склад данных" появился относительно недавно, хотя сама идея отнюдь не нова. Новое здесь - это растущие возможности складов данных, опирающиеся на прогресс в сфере баз данных. Так, распределенные склады - это неизбежное следствие развития технологий распределенных баз данных. Распределенность может иметь относительно простые формы, например несколько разрозненных подчиненных складов данных, управляемых посредством клиент-серверного ПО промежуточного слоя (ODBC, IDAPI, DRDA и др.). С другой стороны, возможны и более сложные модели, когда над распределенными компонентами, где выполняются приложения DSS/EIS, поддерживается глобальная схема.

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

Перспективы

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

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

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

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

Литература

J. Bischoff. Achieving Warehouse Success. - Database Programming & Design, July 1994, 26.
R. Cafasso. Users Warehouse Data on the Cheap. - Computerworld, December 1994, 1.
E. U. Harding. Parallel Technology Meets the Warehouse. - Software Magazine, November 1994, 19-20.
W. H. Inmon. Building the Data Warehouse. - Wellesley, MA: QED Publishing Group, 1992.
W. H. Inmon. Shoud We Rewrite History? - Database Programming & Design, March 1992.
P. Uhrowczik. Information Warehouse Archtecture. - Proceedings of DB/Expo 93, San Francisco, May 5, 1993.

Ссылки

W. H. Inmon. Making Sense of Chaos. - Database Programming & Design, January 1993.
W. H. Inmon. Building the Data Warehouse. - Wellesley, MA: QED Publishing Group, 1992, 29-33. W. H. Inmon. Building the Data Warehouse, 32.
C. Kolovson. Indexing Techniques for Historical Databases. В книге Temporal Databases: Thery, Design, and Implementation, ed. A. Tansel. - Redwood City, CA: The Benjamin/Cumming Publishing Company, 1993, 418-432.
W. H. Inmon. Building the Data Warehouse, 42-50.
W. H. Inmon. Building the Data Warehouse, 160-167.
P. Uhrowczik. Information Warehouse Archtecture. - Proceedings of DB/Expo 93, San Francisco, May 5, 1993, 107.
См. обсуждение в статье W. H. Inmon. Shoud We Rewrite History? - Database Programming & Design, March 1992, 70.

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