Извлечение данных

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

Очистка данных

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

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

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

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

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

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

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

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

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

Загрузка данных

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

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

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

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

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

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

Обновление данных

в большинстве баз данных поддержки принятия решений (но не во всех) требуется периодическое обновление данных для поддержания их актуальности. Обновление обычно предусматривает частичную зафузку, хотя для некоторых систем поддержки принятия решений требуется удаление всех данных и их полная перезагрузка. При обновлении возникают те же проблемы, что и при загрузке, и, кроме того, может потребоваться, чтобы обновление выполнялось в то время, когда пользователи обращаются к базе данных. (См. раздел 9.5 главы 9, а также [9.2] и [9.6].)

Банки оперативных данных

Банки оперативных данных представляют собой предметно-ориентированные, интегрированные, изменчивые, т.е. обновляемые, текущие, или почти текущие, коллекции данных [21.19]. Другими словами, банки оперативных данных - это специализированные базы данных. Термин пред.метно-ориентированные означает, что рассматриваемые данные представляют некоторую конкретную предметную область, например заказчиков, продукты и т.п. Банки оперативных данных могут использоваться для разных целей: как область накопления для физической реорганизации извлеченных оперативных данных, для выдачи оперативных отчетов, а также для поддержки оперативных решений. Кроме того, банки оперативных данных могут служить местом консолидации данных, если оперативные данные поступают из нескольких источников. Поэтому они могут быть предназначены для многих целей.

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

21.5. Хранилища данных и ]У1агазины данных

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

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