Рис. 21. Обобщенная структура процесса ETL
Извлечение данных из разнотипных источников и перенос их в хранилище данных с целью дальнейшей аналитической обработки связаны с рядом проблем, основными из которых являются нижеследующие.
Поэтому для переноса исходных данных из различных источников в ХД следует использовать специальный инструментарий, который должен извлекать данные из источников различного формата, преобразовывать их в единый формат, поддерживаемый ХД, а при необходимости — производить очистку данных от факторов, мешающих корректно выполнять их аналитическую обработку. Такой комплекс программных средств получил обобщенное название ETL (от англ. extraction, transformation, loading — «извлечение», «преобразование», «загрузка»). Сам процесс переноса данных и связанные с ним действия называются ETL-процессом, а соответствующие программные средства — ETL-системами.
Приложения ETL извлекают информацию из одного или нескольких источников, преобразуют ее в формат, поддерживаемый системой хранения и обработки, которая является получателем данных, а затем загружают в нее преобразованную информацию. Изначально ETL-системы использовались для переноса информации из более ранних версий различных информационных систем в новые. В настоящее время ETL-системы все более широко применяются именно для консолидации данных с целью их дальнейшего анализа. Очевидно, что поскольку ХД могут строиться на основе различных моделей данных (многомерных, реляционных, гибридных), то и процесс ETL должен разрабатываться с учетом всех особенностей используемой в ХД модели. Кроме того, желательно, чтобы ETL-система была универсальной, то есть могла извлекать и переносить данные как можно большего числа типов и форматов.
Независимо от особенностей построения и функционирования ETL-система должна обеспечивать выполнение трех основных этапов процесса переноса данных (ETL-процесса).
Перемещение данных в процессе ETL можно разбить на последовательность процедур, представленных следующей функциональной схемой (рис. 21).
Рис. 21. Обобщенная структура процесса ETL
1. Извлечение. Данные извлекаются из источников и загружаются в промежуточную область.
2. Поиск ошибок. Производится проверка данных на соответствие спецификациям и возможность последующей загрузки в ХД.
3. Преобразование. Данные группируются и преобразуются к виду, соответствующему структуре ХД.
4. Распределение. Данные распределяются на несколько потоков в соответствии с особенностями организации процесса их загрузки в ХД.
5. Вставка. Данные загружаются в хранилище-получатель.
С точки зрения процесса ETL архитектуру ХД можно представить в виде трех компонентов (рис. 22), таких как:
Рис. 22. Потоки данных в ETL
Перемещение данных от источника к получателю называется потоком данных. Требования к организации потоков данных описываются аналитиком.
ETL часто рассматривают как просто подсистему переноса данных из различных источников в централизованное хранилище. Что касается самих хранилищ данных, то они, строго говоря, не связаны с решением какой-либо конкретной аналитической задачи. Задача хранилища — обеспечивать надежный и быстрый доступ к данным, поддерживать их хронологию, целостность и непротиворечивость. Поэтому на первый взгляд ETL оказывается отделенным от собственно анализа данных. Однако такой взгляд на ETL не позволит добиться преимуществ, которые можно получить, если рассматривать его как неотъемлемую часть аналитического процесса.
Опытный аналитик знает особенности и характер данных, циркулирующих на различных уровнях корпоративной информационной системы, частоту их обновления, степень «загрязненности», уровень их значимости и т.д. Это дает ему возможность с помощью комбинации различных методов преобразования данных в ETL добиться достаточного уровня обобщения и качества данных, попавших в хранилище, выбрать оптимальный регламент и технические требования его пополнения. Последнее особенно важно для организаций со сложной многоуровневой филиальной структурой и большим количеством подразделений.
Например, если известно, что информация, поступающая из определенных подразделений фирмы, является самой важной и полезной, а также часто анализируется, то в регламент переноса данных в хранилище можно внести соответствующие приоритеты.
Таким образом, ETL следует рассматривать не только как процесс переноса данных из одного приложения в другое, но и как инструмент их подготовки к анализу.
Начальным этапом процесса ETL является процедура извлечения записей из источника данных и подготовка содержащейся в них информации к процессу преобразования.
При разработке процедуры извлечения данных в первую очередь необходимо определить регламент загрузки ХД и соответственно частоту выгрузки данных из OLTP-систем или отдельных источников. Например, выгрузка может производиться по истечении заданного временного интервала (день, неделя, месяц или квартал). В некоторых случаях предусматривается возможность внерегламентного извлечения данных после завершения определенного бизнес-события (приобретение нового бизнеса, открытие филиала, поступление большой партии товаров). В зависимости от объема извлекаемых данных, сложности доступа к ним и скорости работы оборудования, выгрузка данных занимает определенное время, которое так и называют — «окно выгрузки». Очевидно, что в течение «окна выгрузки» резко увеличивается нагрузка на компьютерную сеть организации и ее работа может оказаться частично или полностью парализованной. Особенно это актуально для OLTP-систем, где в такие периоды может резко возрасти время ожидания отклика. Поэтому «окно выгрузки» стараются выбрать так, чтобы оно в минимальной степени влияло на рабочий процесс, например в обеденный перерыв, сразу по завершении рабочего дня или ночью.
Если выгрузку данных производить более часто, то, с одной стороны, количество «окон загрузки» увеличивается, но поскольку за меньший период в OLTP-системе накапливается меньше изменений, то «окна загрузки» становятся короче и нагрузка на систему — ниже.
Процедуру извлечения можно реализовать двумя основными способами.
1. Извлечение данных с помощью специализированных программных средств (рис. 23).
Рис. 23. Первый способ извлечения данных в ETL
Преимущества данного способа заключаются в том, что использование специализированных программ позволяет, во-первых, избежать необходимости оснащать OLTP-системы средствами выгрузки, во-вторых, учитывать особенности всего ETL-процесса уже в процессе выгрузки. В случае, когда данные извлекаются из локальных источников (отдельных документов, таблиц и т.д.), альтернативы использованию специальных средств нет, поскольку такие виды источников данных не содержат средств выгрузки данных.
2. Извлечение данных средствами той системы, в которой они хранятся (рис. 24).
Рис. 24. Второй способ извлечения данных в ETL
Поскольку средства «самовыгрузки» разрабатываются с учетом особенностей структуры данных OLTP-системы, это позволяет адаптировать процедуру извлечения к структуре извлекаемых данных, что в ряде случаев делает процесс более эффективным.
После извлечения данные помещаются в так называемую промежуточную область, где для каждого источника данных создается своя таблица или отдельный файл (или и то и другое). В некоторых случаях, когда требуется выгрузить данные из нескольких источников одного типа, для них создается общая таблица; одно из ее полей указывает на источник, из которого были взяты данные. Пример подобной схемы организации выгрузки приведен на рис. 25.
Чтобы начать процесс извлечения данных, в общем случае необходимо использовать некоторую служебную информацию:
Рис. 25. Схема организации ETL
Перед тем как приступить к процессу извлечения данных, необходимо определить, в каких именно источниках хранятся данные, которые должны попасть в хранилище. Все источники можно разделить на две группы — расположенные в корпоративных информационных системах и на локальных компьютерах отдельных пользователей. С точки зрения соблюдения регламента и периодичности загрузки данных в ХД предпочтительны источники из первой группы, поскольку они также функционируют в соответствии с определенным порядком, который проще согласовать с периодичностью загрузки данных в хранилище. Что касается источников на локальных ПК, то обычно никаких сколь-нибудь строгих правил работы с ними не устанавливается: пользователи включают и выключают компьютеры, когда хотят; постоянно возникают те или иные проблемы с сетью и т.д. Тем не менее именно на локальных компьютерах часто собирается очень ценная для анализа информация. Поэтому при выборе источников данных для загрузки в ХД необходимо учитывать следующие факторы:
Как правило, приходится искать компромисс между этими факторами. Например, данные могут представлять несомненную ценность для анализа, но сложность их извлечения или некорректность структуры может свести на нет все преимущества от их использования. В другом случае данные легкодоступны и не требуют дополнительной обработки при загрузке в ХД, но при этом практически не представляют интереса с точки зрения анализа.
После того как источники, из которых будут извлекаться данные, выбраны, необходимо определить, все ли имеющиеся в источниках данные нужны в ХД.
Если извлекать нужно не все записи подряд, а только определенные, аналитик может описать набор условий, которые позволят отобрать только записи, представляющие интерес. Например, можно поставить условие, что записи, которые содержат информацию о продажах на сумму меньше заданной, извлекать и помещать в ХД не нужно, поскольку их ценность с точки зрения результатов анализа ничтожна.
Пример
Легко представить, что посетитель супермаркета зашел туда случайно: не для покупки товара, а чтобы переждать дождь, встретиться с кем-то, помочь донести сумки и т.д. При этом он приобретает коробку спичек, авторучку или другую мелочь, которую мог купить и на обычном уличном лотке. Однако даже для спичечного коробка пробивается чек и создается соответствующая запись в регистрирующей системе. И запись о покупке спичечного коробка за 50 коп. требует места на диске или в памяти не меньше, чем о продаже бутылки коньяка за 1000 руб. В результате после агрегирования данных о продажах за день по отделу выясняется, что зарегистрировано 100 продаж, которые дали в сумме 300 руб., и 10 продаж на общую сумму 15 000 руб. Возникает вопрос: нужно ли тратить время на обработку и хранение огромного количества записей, вклад которых в результат анализа будет ничтожен. Более того, включение в анализ информации о мелких покупках, сделанных случайными клиентами, может только помешать, например, построению модели поведения постоянных клиентов. Поэтому аналитик может задать условие, что извлекаться должны лишь те записи, в которых значение поля «Сумма» не менее 20 руб.
Другой важный момент — определение глубины выгрузки данных по времени. Очевидно, что все записи понадобятся только при первичном заполнении хранилища. В процессе его пополнения из источников должны извлекаться лишь те записи, которые добавлялись или изменялись после прошлого извлечения. Иногда хранилища полностью очищают и перезагружают. Но это возможно только в случае, если ХД не очень большое и процесс регенерации занимает не слишком много времени, а также если регенерация происходит редко и за промежуток времени между ними большая часть данных изменяется или утрачивает актуальность.
Вопрос определения глубины выгрузки актуален только при начальной загрузке хранилища, когда требуется определить, информация за какой период времени является актуальной. В простейшем случае, когда никаких соображений на этот счет нет, можно загрузить все имеющиеся записи. Однако этот подход не всегда оптимален, поскольку в хранилище может оказаться много информации, не представляющей ценности для анализа в связи с потерей актуальности. Таким образом, выбор глубины выгрузки исторических данных должен обеспечить компромисс между объемом выгружаемых данных и их ценностью с точки зрения анализа.
Процедура определения глубины выгрузки облегчается, если в источнике данных присутствует поле, в котором указывается время создания и изменения каждой записи. В этом случае отбирать извлекаемые записи по времени можно с помощью несложного фильтра.
При повторных загрузках ХД важно не только определить глубину выгрузки, но и организовать поиск измененных данных вообще. Для этой цели разработаны различные методики, например использование меток времени. Для каждой измененной записи создается метка, указывающая на время изменения, и при очередной выгрузке извлекаются только те записи, метки времени которых созданы позднее прошлого извлечения.
Если источником данных является реляционная СУБД, то часто используются так называемые триггеры (triggers) — специальные процедуры, запускаемые автоматически при выполнении операций вставки, обновления или удаления. Триггеры позволяют сохранять измененные записи в специальной таблице (таблице изменений), из которой они могут быть извлечены при следующей выгрузке. Однако использование триггеров существенно увеличивает нагрузку на систему, поэтому, если система уже работает с большой нагрузкой, к применению триггеров надо подходить осторожно.
Процесс извлечения данных в рамках ETL существенно зависит от типов и структуры источников данных. Можно выделить три разновидности источников данных, с которыми чаще всего сталкиваются организаторы аналитических проектов.
Базы данных (SQL Server, Oracle, Firebird, Access и т.д.). В большинстве случаев извлечение данных из баз данных не вызывает проблем, поскольку структура данных в них жестко задана, соответствует определенным стандартам и общепринятым требованиям. Кроме того, во многих СУБД предусмотрен автоматический контроль за целостностью и непротиворечивостью данных.
Структурированные файлы различных форматов. Такие файлы очень широко распространены, поскольку средства их создания (в большинстве случаев это типовые офисные приложения) общедоступны и не требуют высокой квалификации персонала и высокой производительности систем. К таким источникам относятся текстовые файлы с разделителями, файлы электронных таблиц (например, Excel, CSV-файлы, HTML-документы и т.д.). Здесь проблем больше, поскольку пользователь может допускать ошибки, пропуски, вводить противоречивые данные, терять фрагменты данных и т.д. Пользователи офисных приложений часто понятия не имеют о том, что такое тип данных, и уж тем более не связывают вводимые ими данные с задачами будущего анализа. Очевидно, что в этой ситуации при извлечении данных можно столкнуться с чем угодно. Единственным плюсом является то, что для доступа к типовым структурированным данным можно применять такие стандартные средства, как ODBC и ADO.
Неструктурированные источники. Как правило, эта ситуация требует особого внимания. Если избежать использования неструктурированных источников не получается, нужно применить специальные средства их преобразования в структурированный вид. Когда источник невелик, возможно, это удастся сделать вручную. Но в большинстве случаев приходится разрабатывать специальный инструментарий, учитывающий особенности организации данных в источнике и то, какую структуру из них следует создать. Существуют также готовые программные системы для решения этой задачи. Конечная цель структурирования — так упорядочить данные в файле, чтобы их в том или ином виде можно было загрузить в реляционную таблицу.
Таким образом, извлечение данных из OLTP-систем, СУБД и отдельных структурированных источников в рамках ETL-процесса может оказаться задачей достаточно сложной в техническом плане и важной для эффективного анализа данных. Поэтому разработкой и организацией процесса извлечения данных должны заниматься как технические специалисты, так и аналитики.
Наличие «грязных» данных — одна из важнейших и трудно формализуемых проблем аналитических технологий вообще и ХД в частности. Очистка данных обязательна при их перегрузке в хранилище, и при разработке стратегии ETL этому уделяется большое внимание. Следует отметить, что, помимо очистки данных перед их загрузкой в хранилище, пользователь может выполнить дополнительную очистку средствами аналитической системы уже после выполнения запроса к ХД. Такое дублирование вполне оправданно по ряду причин.
Таким образом, первичная очистка данных в процессе ETL носит в большей степени технический характер. Ее основная задача — подготовить данные к загрузке в хранилище. Вторичная очистка в аналитической системе является пользовательской, она направлена на подготовку данных к решению конкретной аналитической задачи. Поэтому оба этапа очистки одинаково важны и необходимы.
Чтобы разработать методику очистки данных в процессе ETL, необходимо определить критерии оценки их качества. Одним из таких критериев является критичность ошибок. В этой связи данные могут быть разделены на три категории:
Существует несколько проблем, из-за которых данные нуждаются в очистке. Наиболее широко распространены проблемы, связанные с нарушением структуры данных:
Для каждого структурного уровня данных — отдельной ячейки, записи, целой таблицы, отдельной БД или множества БД — характерны свои факторы, снижающие качество данных. Наиболее типичные ошибки, соответствующие структурным единицам БД, представлены в табл. 6.
Таблица 6. Типичные ошибки, соответствующие структурным единицам БД
|
Ячейка |
Запись |
Таблица |
Отдельная БД |
Множество БД |
|
Орфографические ошибки |
Противоречия между ячейками |
Дублирование записей |
Целостность данных |
Несоответствия структуры данных |
|
Пропуски в данных | ||||
|
Фиктивные значения |
Одинаковые наименования различных атрибутов | |||
|
Логические несоответствия |
Противоречивые записи |
Противоречия |
Различное представление однотипных данных | |
|
Закодированные значения |
Различная временная шкала | |||
|
Составные значения |
На уровне отдельной ячейки таблицы наиболее характерны следующие ошибки.
Орфографические ошибки или опечатки могут привести к неправильному пониманию или искажению данных. Например, ошибка в названии фирмы приведет к появлению двух разных фирм с одинаковыми реквизитами, что вызовет противоречия, ошибки в отчетах и т.д.
Пропуски данных — отсутствие данных в тех ячейках, где они должны быть. Пропуски могут быть вызваны ошибкой оператора или отсутствием соответствующей информации. Например, что означает отсутствие информации о продажах в супермаркете на определенную дату? Если в этот день магазин был закрыт, то есть продаж не было, в соответствующей ячейке должен стоять ноль. Если же магазин работал, то, скорее всего, имеет место ошибка оператора. Однако при автоматической загрузке огромного количества данных, что имеет место в большинстве корпоративных систем, разобраться с каждым отдельным случаем пропуска данных невозможно. Поэтому на этапе очистки данных в ETL необходимо разработать методику восстановления пропущенных данных, которая как минимум делала бы их корректными с точки зрения совместимости со структурой хранилища. Что касается корректности с точки зрения анализа, то большинство аналитических систем содержит средства восстановления пропущенных данных способом, который предпочтет аналитик (начиная от установки значения вручную до применения сложных статистических методов).
Фиктивные значения — данные, не имеющие смысла, никак не связанные с описываемым ими бизнес-процессом. Подобная ситуация возможна, если оператор системы OLTP, не располагая необходимой информацией, ввел в ячейку произвольную последовательность символов. Оператор бывает вынужден это сделать, когда система не позволяет продолжать работу, пока соответствующая ячейка не будет заполнена. Так, если клиент забыл указать в анкете возраст, то оператор может ввести значение 0 или 999. При этом лучше, если значение явно «не лезет ни в какие ворота», поскольку в таком случае вероятность того, что оно будет принято за реальное, уменьшается. Вообще, обнаружить и отфильтровать фиктивные значения довольно трудно, поскольку понятие «смысл» является субъективным и не поддается формализации. Поэтому на этапе очистки данных средствами ETL можно выработать только общие формальные методы обнаружения фиктивных значений и борьбы с ними. Например, можно установить правило: «Если возраст клиента больше 150, то заменить его на значение 0». Когда при последующем анализе аналитик встретит такое значение, он поймет, что значение фиктивное, и примет меры к его замене на более правдоподобное (например, среднее по выборке). Существует и другой способ борьбы с фиктивными значениями. Можно проинструктировать операторов OLTP-систем или персонал, который занимается сводками данных в офисных приложениях, что при отсутствии реальных данных должен вводиться специальный код, который при обработке в процессе ETL распознавался бы как фиктивное значение. Затем к таким данным можно применить обработку, предписанную аналитиком. Наконец, если фиктивные значения являются аномальными (что чаще всего и имеет место), то они могут быть обнаружены и скорректированы средствами аналитической системы.
Логические несоответствия возникают, если значение в ячейке не соответствует логическому смыслу поля таблицы. Например, вместо наименования фирмы указан ее банковский счет.
Закодированные значения — сокращения, аббревиатуры, замена наименований числовыми кодами.
Составные значения появляются в файлах, где структура полей жестко не задана, например в обычных текстовых файлах, электронных таблицах и т.д. Составное значение может получиться, если оператор регистрационной системы ошибочно ввел два отдельных значения или более в ячейку, предназначенную для одного значения. Например, в системе предусмотрены отдельные поля для фамилии, имени и отчества клиента, а неопытный оператор ввел все эти значения в одно поле Фамилия. Другой вариант: для каждого из элементов адреса клиента предусмотрены отдельные поля, а весь адрес оказался введен в поле Индекс.
На уровне записи возникают в основном проблемы противоречивости данных в различных ячейках. Например, сумма, на которую был продан товар, не соответствует произведению цены за единицу и количества проданных единиц.
На уровне таблицы основными проблемами являются дублирующие и противоречивые записи.
Дубликаты — это полностью идентичные записи. Сами по себе они не вызывают нарушений в структуре данных, и их наличие не является критичным. Однако дубликаты также могут вызвать ряд проблем.
Аналитические системы обычно содержат средства для обнаружения и удаления дублирующих записей. Поэтому если в процессе ETL борьба с дубликатами не была предусмотрена, это можно будет сделать при подготовке данных к анализу непосредственно в аналитической системе.
Противоречивыми являются записи, которые для двух различных объектов содержат одинаковые значения уникальных атрибутов. Например, в базе данных клиентов для двух разных организаций указаны одинаковые банковские реквизиты.
На уровне отдельной БД основной проблемой является нарушение целостности данных, которое заключается в том, что происходит рассогласование между различными объектами БД. Например, если в БД есть документ, сопровождающий сделку с каким-либо клиентом, то, как правило, при создании нового документа имя клиента не вводится вручную, а выбирается из списка клиентов, содержащегося в другой таблице БД и открывающегося при заполнении соответствующего поля. В результате документ содержит не собственно имя клиента, а ссылку на соответствующий объект другой таблицы. Если по какой-либо причине объект (то есть запись о клиенте) будет удален, то документ не сможет быть сформирован, из-за того что объект, на который имеется ссылка, оказывается недоступен.
На уровне множества БД возникают проблемы, связанные с отличиями структуры данных в различных базах:
Стратегия очистки данных должна разрабатываться с учетом особенностей предметной области, функционирования OLTP-систем и порядка сбора данных. Например, принимая решение о включении в процесс обработки данных ETL средств для борьбы с дубликатами, аналитик должен выяснить, могут ли в бизнес-процессе возникать идентичные объекты или события, происходящие в одном временном интервале. Если да, то две одинаковые записи, определяемые как дубликаты, могут описывать разные объекты или события. Очевидно, что в этом случае к обработке дубликатов следует подходить с осторожностью, чтобы не потерять полезную информацию.
Кроме того, необходимо помнить, что полностью очистить данные удается очень редко. Существуют проблемы, которые не получается решить независимо от степени приложенных усилий. Бывают случаи, когда некорректное применение методов очистки данных только усугубляет ситуацию. Иногда использование очень сложных алгоритмов очистки увеличивает время переноса данных в ХД до неприемлемой величины. Поэтому не всегда следует стремиться к полной очистке данных. Лучше обеспечить компромисс между сложностью используемых алгоритмов, затратами на вычисление, временем, требуемым на очистку, и ее результатами. Если достоверность каких-то данных не влияет на результаты анализа, то от их очистки, возможно, следует вообще отказаться.
Этап ETL-процесса, следующий за извлечением, — преобразование данных. Его цель — подготовка данных к размещению в ХД и приведение их к виду, наиболее удобному для последующего анализа. При этом должны учитываться некоторые выдвигаемые аналитиком требования, в частности, к уровню качества данных. Поэтому в процессе преобразования может быть задействован самый разнообразный инструментарий, начиная от простейших средств ручного редактирования данных до систем, реализующих весьма сложные методы обработки и очистки данных.
В процессе преобразования данных в рамках ETL чаще всего выполняются следующие операции (рис. 26):
Рис. 26. Процесс преобразования данных в ETL Рассмотрим каждую из этих операций более детально.
Во многих случаях данные поступают в хранилище, интегрируясь из множества источников, которые создавались с помощью различных программных средств, методологий, соглашений, стандартов и т.д. Данные из таких источников могут отличаться своей структурной организацией: соглашениями о назначении имен полей и таблиц, порядком их описания, форматами, типами и кодировкой данных, например точностью представления числовых данных, используемыми разделителями целой и дробной частей, разделителями групп разрядов и т.д. Следовательно, во многих случаях извлеченные данные непригодны для непосредственной загрузки в ХД из-за отличия их структуры от структуры соответствующих целевых таблиц ХД.
При этом если таблицы фактов чаще всего соответствуют требованиям ХД, то таблицы измерений нуждаются в дополнительной обработке и, может быть, объединении.
Так, если в источнике, полученном из одного филиала, информация о покупателях хранится в поле Customer_Id, а в источнике, полученном из другого филиала, — в поле Clients_Name, то для создания одного измерения Покупатель придется решать задачу их объединения.
Дополнительная обработка структуры данных также требуется в ситуации, когда одно подразделение фирмы представляет информацию о цене и количестве проданных товаров, а другое — о количестве товаров и общей сумме продаж. В таком случае потребуется привести информацию о продажах, полученную из обоих источников, к общему виду.
Как правило, в качестве источников данных для хранилищ выступают системы оперативной обработки данных (OLTP-системы), учетные системы, файлы различных СУБД, локальные файлы отдельных пользователей и т.д. Общим свойством всех этих источников является то, что они содержат данные с максимальной степенью детализации — сведения о ежедневных продажах или даже о каждом факте продажи в отдельности, об обслуживании каждого клиента и т.д. Распространено мнение, что такое детальное воспроизведение событий в исследуемом бизнес-процессе только пойдет на пользу, поскольку данные никогда не бывают лишними и чем больше их будет собрано, тем точнее окажутся результаты анализа.
Это не совсем так. Элементарные события, из которых состоит бизнес-процесс, например обслуживание одного клиента, выполнение одного заказа и т.д., которые также называют атомарными (то есть неделимыми), по своей сути являются случайными величинами, подверженными влиянию множества различных случайных факторов — от погоды до настроения клиента. Следовательно, информация о каждом отдельном событии в бизнес-процессе практически не имеет ценности. Действительно, на основании информации о продажах за один день нельзя сделать вывод обо всех особенностях торговли. Точно так же нельзя выработать стратегию работы с клиентами на основе исследования поведения одного клиента.
Иными словами, для достоверного описания предметной области использование данных с максимальным уровнем детализации не всегда целесообразно, поэтому наибольший интерес для анализа представляют данные, обобщенные по некоторому интервалу времени, по группе клиентов, товаров и т.д. Такие обобщенные данные называются агрегированными (иногда агрегатами), а сам процесс их вычисления — агрегированием.
В результате агрегирования большое количество записей о каждом событии в бизнес-процессе заменяется относительно небольшим количеством записей, содержащих агрегированные значения. Например, вместо информации о каждой из 365 ежедневных продаж в году в результате агрегирования будут храниться 52 записи с обобщением по неделям, 12 — по месяцам или 1 — за год. Если цель анализа — разработка прогноза продаж, то для краткосрочного оперативного прогноза достаточно использовать данные по неделям, а для долгосрочного стратегического прогноза — по месяцам или даже по годам.
Фактически при агрегировании производится объединение нескольких записей в одну с вычислением агрегированного значения на основе значений каждой записи. При вычислении агрегатов может быть использовано несколько способов. □ Среднее — для данных, расположенных в пределах интервала, в котором они обобщаются, вычисляется среднее значение. Затем все записи из данного интервала заменяются одной, содержащей их среднее значение (рис. 27).
Рис. 27. Пример агрегирования
Закономерен вопрос: нужно ли агрегировать все данные без разбору по всем возможным уровням обобщения или к этому следует подходить внимательно? Для ответа необходимо изучить наиболее вероятные направления использования данных в ХД. Однако если хранилище находится на стадии разработки и внедрения и методика его использования еще не до конца проработана, то сделать это трудно. Тем не менее, если опросить потенциальных пользователей ХД, что именно они хотят получить, возможно, некоторые сведения на этот счет удастся разыскать.
Из всех возможных вариантов агрегирования следует выбрать наиболее значимые с точки зрения планируемых направлений анализа, а от остальных отказаться. Очевидно, можно отказаться от агрегатов, которые имеют малое число подчиненных агрегированных значений (например, агрегирование ежемесячных продаж за квартал), поскольку их легко вычислить в процессе анализа. Или, наоборот, можно отказаться от агрегатов с максимальной степенью детализации (например, агрегирование ежедневных продаж). Второй вариант наиболее предпочтителен, поскольку на первый взгляд сулит существенную экономию, так как число дней в году умножается на число товаров и продавцов. Однако если данные о продажах являются разреженными, то есть не каждый товар продается ежедневно, то экономия может оказаться весьма незначительной.
Выбор нужных агрегатов всегда определяется особенностями бизнеса. При этом следует помнить, что агрегаты, требуемые для анализа, могут быть вычислены и непосредственно при выполнении аналитического запроса к ХД, хотя тем самым время его выполнения несколько увеличится. Подобный подход позволяет, например, отказаться от агрегирования редко используемых данных.
Таким образом, выбор правильной стратегии агрегирования данных в ETL — сложная и противоречивая задача. Увеличение числа агрегатов в ХД приводит к увеличению его размеров и сложности структуры данных. Снижение числа агрегатов в ХД может привести к необходимости их вычисления в процессе выполнения аналитических запросов, что увеличит время ожидания пользователя. Следовательно, необходимо обеспечить разумный компромисс между этими факторами. Существует и более простое правило, определяющее стратегию агрегирования: создавайте только те агрегаты, которые с большой долей вероятности понадобятся при анализе данных.
Часто данные в источниках хранятся с использованием специальных кодировок, которые позволяют сократить избыточность данных и тем самым уменьшить объем памяти, требуемой для их хранения. Так, наименования объектов, их свойств и признаков могут храниться в сокращенном виде. В этом случае перед загрузкой данных в хранилище требуется выполнить перевод таких сокращенных значений в более полные и, соответственно, понятные.
Например, согласно заведенному в организации порядку идентификационный номер операции может быть закодирован в виде 06–04–12–62, где 06–04 — число и месяц, 12 — код товара, 62 — код региона. Такое представление позволяет хранить данные очень компактно. Однако для заполнения соответствующих измерений в многомерной модели запись необходимо декодировать.
Кроме того, часто возникает необходимость конвертировать числовые данные, например преобразовать вещественные в целые, уменьшить избыточную точность представления чисел, использовать экспоненциальный формат и т.д.
В процессе загрузки в ХД может понадобиться вычисление некоторых новых данных на основе существующих, что обычно сопровождается созданием новых полей. Например, OLTP-система содержит информацию только о количестве и цене проданного товара, а в целевой таблице ХД есть поле Сумма. Тогда в процессе преобразования необходимо вычислить сумму как произведение цены на количество проданных единиц товара. Таким образом, будет создано поле, содержащее новую информацию.
Еще одним возможным примером новых данных, создаваемых в процессе обработки, являются экономические, финансовые и другие показатели, которые могут быть вычислены на основе имеющихся данных. Так, на основе данных о продажах можно рассчитать рейтинг популярности товаров и создать новое поле, в котором для каждого товара будет указано соответствующее рейтинговое значение (например, по пятибалльной системе).
Создание новой информации на основе имеющихся данных тесно связано с таким важным процессом, как обогащение данных, которое может производиться (частично или полностью) на этапе преобразования данных в ETL. Агрегирование также может рассматриваться как создание новых данных.
Сбор данных в процессе ETL производится из большого числа источников, многие из которых не содержат автоматических средств поддержки целостности, непротиворечивости и корректного представления данных. В связи с этим при переносе информации в ХД приходится сталкиваться с потоками «грязных» данных, которые могут стать причиной неправильных результатов анализа и даже сделать невозможным применение некоторых аналитических алгоритмов и методов. По этой причине в процессе ETL применяется очистка — процедура корректировки данных, которые в каком-либо смысле не удовлетворяют определенным критериям качества, то есть содержат нарушения структуры данных, противоречия, пропуски, дубликаты, неправильные форматы и т.д.
Некоторые проблемы в данных являются критичными и даже не позволяют выполнить загрузку данных в ХД (как правило, это нарушения структуры и некорректные форматы данных). Другие проблемы менее критичны, не мешают переносу данных в ХД, но не позволяют их корректно анализировать (пропуски, противоречия и дубликаты). Критичные проблемы в данных должны устраняться непосредственно в процессе ETL. Некритичные факторы, снижающие качество данных, могут устраняться как в процессе ETL, так и при подготовке их к анализу в аналитической системе.
Очистка данных — одна из наиболее важных и в то же время наиболее сложных и трудно поддающихся формализации задач ETL-процесса, поскольку набор факторов, снижающих качество данных, весьма разнообразен и может постоянно меняться. Поэтому очистке данных при разработке ETL-процессов уделяют большое внимание.
В принципе, преобразование данных может быть выполнено на любом этапе ETL-процесса. Но иногда требуется выбрать оптимальное место для осуществления преобразования. Некоторые виды преобразований удобнее выполнять «на лету», в процессе извлечения данных из источника, другие — в промежуточной области, третьи — в процессе загрузки данных в ХД. Рассмотрим преимущества и недостатки этих вариантов.
Таким образом, все операции преобразования, которые могут потребоваться при переносе данных в ХД, обычно не сосредотачиваются на одном шаге ETL-процесса, а распределяются по различным этапам в зависимости от того, где выполнение преобразования более эффективно.
После того как данные извлечены из различных источников и выполнены преобразование, агрегация и очистка данных, осуществляется последний этап ETL — загрузка данных в хранилище. Процесс загрузки заключается в переносе данных из промежуточных таблиц в структуры хранилища данных. От продуманности и оптимальности процесса загрузки данных во многом зависит время, требуемое для полного цикла обновления данных в ХД, а также полнота и корректность данных в хранилище.
Первыми в процессе загрузки данных в ХД обычно загружаются таблицы измерений, которые содержат суррогатные ключи и другую описательную информацию, необходимую для таблиц фактов.
При загрузке таблиц измерений требуется и добавлять новые записи, и изменять существующие. Например, измерение Клиент может содержать десятки тысяч клиентов, при этом информация меняется только для незначительного их числа (не более 10%). Нужно добавить данные о новых клиентах и одновременно модифицировать информацию о существующих.
При добавлении новых данных в таблицу измерений требуется определить, не существует ли в ней соответствующая запись. Если нет, то она добавляется в таблицу. В противном случае могут использоваться различные способы обработки изменений в зависимости от того, нужно ли поддерживать старую информацию в хранилище с целью ее последующего анализа. Например, если изменился только адрес клиента, то в большинстве случаев нет необходимости хранить старый адрес, поэтому запись может быть просто обновлена.
У быстро растущих компаний часто возникают новые регионы продаж. Например, если сначала регионом продаж была только Рязанская область, то впоследствии он может расшириться на весь Центральный федеральный округ (ЦФО) и далее на всю Российскую Федерацию. Если в ХД требуется хранить как старую географическую иерархию, так и обновленную, можно создать дополнительную таблицу измерений, записи которой будут содержать и старые географические данные, и новые. В качестве альтернативы можно добавить дополнительные поля в существующие таблицы, чтобы сохранить старую информацию и добавить новую.
При загрузке таблицы фактов новая информация обычно добавляется в конец таблицы, чтобы не изменять существующие данные.
Одной из основных проблем данного этапа ETL является то, что далеко не всегда данные загружаются полностью: в загрузке некоторых записей может быть отказано. Отклонение записей происходит по следующим причинам.
При появлении данных, попытка загрузки которых потерпела неудачу, необходимо предусмотреть следующие действия (рис. 28):
Рис. 28. Последовательность действий при наличии отклоненных записей в процедуре загрузки в ХД
Если и повторная попытка загрузки данных не увенчалась успехом, то в хранилище окажутся неполные данные, анализ которых может привести к неправильным выводам. Для решения этой проблемы можно:
При очередной загрузке в ХД переносится не вся информация из OLTP-системы, а только та, которая была изменена в течение промежутка времени, прошедшего с предыдущей загрузки. При этом можно выделить два вида изменений — добавление и обновление (дополнение).
Для обеспечения этих функций загружаемые данные распределяются по двум параллельным потокам (data flow) — потоку добавления и потоку обновления (рис. 29).
Рис. 29. Поток добавления и поток обновления
Для распределения загружаемых данных на потоки используются средства мониторинга изменений в данных. Они фиксируют состояние данных в некоторые моменты времени и определяют, какие данные были изменены или дополнены. Применяются следующие методы:
Распределение загружаемых данных на поток добавления и поток обновления позволяет выполнять перенос данных в хранилище с помощью обычных запросов, не используя какие-либо фильтры для разделения данных на новые и обновляющие.
Обновление данных должно производиться строго в соответствии с требованиями к обеспечению истории данных, то есть не должно приводить к потере уже существующих данных, за исключением особых случаев.
Следует отметить, что при разработке методики загрузки данных в ХД нет общего подхода к тому, как модифицировать таблицы измерений. Например, если изменилось описание некоторого продукта, придется создать новое поле в таблице, чтобы сохранить старое описание и добавить новое. Если требуется сохранить все старые описания продукта, то придется создавать новую запись для каждого изменения и назначать соответствующие ключи.
После завершения загрузки выполняются дополнительные операции над данными, только что загруженными в ХД, перед тем как сделать их доступными для пользователя. Такие операции называются постзагрузочными. К ним относятся переиндексация, верификация данных и т.д.
С точки зрения аналитика, наиболее важной задачей является верификация данных. Прежде чем использовать новые данные для анализа, полезно убедиться в их надежности и достоверности. Для этих целей можно предусмотреть комплекс верификационных тестов. Например:
Кроме того, может оказаться полезным сравнивать данные не только в различных разрезах после их загрузки в ХД, но и с источниками данных. Так, если значения какого-либо показателя в источнике и хранилище равны, то все нормально, в противном случае данные, возможно, некорректны.
Если тестирование показало, что несоответствия, позволяющие заподозрить потерю или недостоверность данных, отсутствуют, то можно считать загрузку данных в ХД успешной и приступать к анализу новой информации.
Довольно часто возникают ситуации, когда данные для анализа приходится импортировать непосредственно из источников, минуя хранилища данных и другие промежуточные системы. Это может потребоваться в случае, когда организация отказалась от использования ХД или когда хранилище имеется, но данные из некоторых источников не могут быть в него загружены по техническим причинам, из-за несоответствия моделям и форматам данных, используемым в ХД.
Таким образом, часть данных поступает в аналитическую систему через ХД с соответствующей очисткой и подготовкой, а другая часть — непосредственно из источников (рис. 30).
Рис. 30. Загрузка данных из локальных источников
Извлечение данных напрямую из источников имеет свои преимущества и недостатки, а также порождает ряд проблем, связанных как непосредственно с процессом извлечения, так и с качеством полученных данных.
Главным преимуществом, которое дает использование хранилищ данных в аналитических технологиях, является повышение эффективности и достоверности анализа данных, особенно для поддержки принятия стратегических решений. Это достигается за счет оптимизации скорости доступа к данным, возможности интеграции данных различных форматов и типов, автоматической поддержки целостности и непротиворечивости, обеспечения хронологии и истории данных.
Тем не менее некоторые организации не используют хранилища данных для консолидации анализируемой информации. При необходимости выполнения анализа данные загружаются в аналитическое приложение непосредственно из источников, где они содержатся, а семантический слой обеспечивается средствами самого аналитического приложения.
Причины отказа от использования ХД могут быть следующими.
1. Организация не располагает достаточными ресурсами (финансовыми, техническими, кадровыми) для разработки, приобретения и поддержки ХД.
2. Унаследованная система аналитической обработки эффективно функционирует с использованием обычной реляционной СУБД, и руководство не видит смысла в дорогостоящем и трудоемком процессе внедрения ХД.
3. Объем анализируемых данных невелик, а применяемые технологии анализа данных несложны. В частности, не требуется поддержка хронологии данных, для анализа используются только данные за актуальный период и т.д.
4. Роль анализа в деятельности организации невысока, администрация не осознала его значимость в получении конкурентных преимуществ.
Таким образом, причин для отказа от использования ХД в аналитическом процессе достаточно много и все они могут быть по-своему аргументированы. В некоторых случаях отказ от ХД дает определенные преимущества: аналитический процесс становится проще и дешевле; нет необходимости разрабатывать концепцию его внедрения; не нужны сложный процесс ETL и другие сопутствующие затраты. Кроме того, процессы, связанные с поддержкой ХД, — интегрирование данных из различных источников и ETL, — если они недостаточно продуманы и некачественно реализованы, способны не только свести на нет все преимущества, которые дает ХД, но и ухудшить ситуацию, породив массу ошибок и проблем с получением данных. Возможно также, что лучше быстро реализовать аналитический процесс в упрощенном варианте, чем годами отлаживать взаимодействие OLTP-систем с ХД.
Отказ от использования ХД для консолидации и интегрирования данных не только снижает эффективность анализа, достоверность и значимость его результата, но и порождает ряд дополнительных проблем как технического, так и методического плана. Конечно, они присутствуют и при использовании ХД, но в этом случае они автоматически решаются самим хранилищем и поддерживающими его программными средствами. При осуществлении прямого доступа к источникам данных пользователь (эксперт, аналитик) вынужден сталкиваться с этими проблемами непосредственно. К таким проблемам относятся следующие.
Необходимость самостоятельно определять тип и формат источника данных. Узнать тип и формат файла можно по его расширению. Однако, если приходится иметь дело с экзотическим форматом или типом файла, этот вопрос может потребовать дополнительного исследования. Например, если речь идет о текстовом файле с разделителями, то TXT-формат известен любому, кто работал на компьютере, поскольку его освоение обычно начинается с создания простейших текстовых файлов. В то же время формат CSV в повседневной работе используется достаточно редко и поэтому большинству пользователей неизвестен. Кроме того, при загрузке данных из СУБД пользователь сталкивается с поиском нужной таблицы, что само по себе не очень сложно, но может занять определенное время.
Отсутствие полноценного семантического слоя того уровня, который имеется в ХД. При работе с ХД, которое обеспечивает семантический слой, преобразующий высокоуровневые запросы пользователей в низкоуровневые запросы к источникам данных, пользователь оперирует такими бизнес-терминами предметной области, как наименования товаров и клиентов, цена, количество, сумма, наценка, скидка и т.д. При работе с источниками данных напрямую аналитик вынужден иметь дело непосредственно с именами полей источника, которые в большинстве случаев вводятся на латинице и не всегда понятны, поэтому приходится тратить время на то, чтобы разобраться, в каком поле содержатся нужные данные.
Отсутствие жесткой поддержки структуры и форматов данных. При непосредственной работе с источниками данных часто приходится иметь дело с файлами, в которых структура и формат данных жестко не заданы. Типичный пример — текстовый файл с разделителями, в котором данные упорядочены в столбцы, отделенные друг от друга однотипными символами-разделителями. В таких файлах могут быть любые нарушения структуры и форматов данных. В них могут содержаться неполные поля и записи, использоваться различные символы — разделители столбцов, произвольные разделители целой и дробной частей и групп разрядов в числах. В одном и том же столбце могут оказаться и строковые, и числовые данные, различные форматы даты и т.д. Особенно это характерно для файлов, которые создавались без учета перспективы анализа данных. В подобной ситуации ничего не остается, кроме как попытаться выполнить корректировку данных средствами, имеющимися в аналитическом приложении. Иногда структура данных в файле оказывается настолько искаженной, что его загрузка в аналитическую систему невозможна. Тогда редактировать данные приходится непосредственно в источнике. И в том и в другом случае ручная корректировка данных является очень трудоемкой и затратной по времени. Если затраты на подготовку данных превышают их ценность с точки зрения анализа, то, возможно, от работы с ними следует вообще отказаться.
Отсутствие автоматических средств поддержки целостности, непротиворечивости и уникальности данных. Эта проблема главным образом возникает при работе с локальными файлами. При извлечении данных может произойти разрыв связей между атрибутами и, как следствие, потеря целостности данных.
Отсутствие средств автоматического агрегирования и создания новых данных. При использовании ХД предусмотрены автоматические агрегирование данных и расчет вычисляемых значений (обычно в процессе ETL). Эти новые данные сохраняются и остаются доступными в любой момент, что ускоряет выполнение аналитических запросов. Когда загрузка данных производится напрямую из источников, агрегирование и вычисление новых данных приходится делать непосредственно в ходе выполнения запросов либо вручную, что существенно снижает скорость работы.
Отсутствие средств автоматического контроля ошибок и очистки данных. Это приводит к тому, что в аналитическую систему загружаются «грязные» данные, зачастую непригодные для анализа, поэтому пользователь должен самостоятельно (визуально и с помощью статистических характеристик или специальных средств, если они доступны) оценить качество данных, степень их пригодности для анализа и применить необходимые методы очистки.
Необходимость настройки механизмов доступа к источникам данных. Для осуществления непосредственного доступа к различным источникам данных обычно используются стандартные механизмы доступа — ODBC, ADO и OLE DB. Чтобы указанные компоненты функционировали правильно, они должны быть соответствующим образом настроены, что также зачастую ложится на плечи пользователя или системного администратора.
Помимо недостатков, использование непосредственного доступа к источникам данных имеет ряд преимуществ.
Таким образом, необходимость в организации непосредственного доступа к различным источникам данных из аналитического приложения возникает даже при наличии ХД.
Наиболее часто встречающимися видами источников данных, доступ к которым производится напрямую, являются:
Текстовые файлы с разделителями (TXT, CSV). Файлы в TXT-формате хорошо известны большинству пользователей (даже непрофессиональных) еще со времен MS-DOS. Для создания таких файлов достаточно использовать простейший текстовый редактор, например Блокнот из набора стандартных программ Windows. Однако эти файлы имеют произвольную структуру данных, поэтому они наиболее уязвимы с точки зрения нарушения структуры, использования некорректных форматов и представлений данных. Так что загрузка и очистка TXT-файлов могут вызвать самые серьезные проблемы, несмотря на то что эти файлы очень просты в создании.
Чтобы создать структурированный текстовый файл, который может быть загружен в аналитическую систему, достаточно упорядочить в нем данные в виде вертикальных столбцов и горизонтальных строк, из которых будут сформированы поля и записи соответственно. Для разделения столбцов должны использоваться однотипные символы-разделители, например табуляция, точка с запятой и др. Можно использовать как один символ, так и несколько идущих подряд символов. При создании файла следует придерживаться нескольких правил.
1. В первой строке файла нужно указать заголовки столбцов в произвольной форме, при этом используются кириллица и пробелы. При загрузке в аналитическую систему заголовки столбцов будут преобразованы в метки полей, что позволит аналитику быстрее разобраться с содержимым источника. Поскольку в TXT-файлах имена полей (в том виде, как они представлены в таблицах файлов БД) отсутствуют, при загрузке в аналитическую систему они будут установлены автоматически в соответствии с правилами, принятыми в данной системе. Например, им по умолчанию могут быть присвоены метки COL1, COL2 или FIELD1, FIELD2 и т.д. Если в первой строке текстового файла над каждым столбцом указано его название, то система при загрузке сможет преобразовать эти названия в имена полей, если каким-либо образом указать, что первая строка содержит заголовки. Однако это возможно только при условии, что названия столбцов не противоречат правилам назначения имен полей в данной аналитической системе, то есть не содержат недопустимых символов, не превышают заданную длину и т.д. Это следует учитывать при создании текстовых файлов с разделителями, которые планируется использовать в качестве источников данных для аналитических систем.
2. Необходимо соблюдать регулярность структуры данных, то есть каждые строка и столбец должны содержать одинаковое число элементов. Если некоторые значения были утеряны, то их можно заменить средними значениями по столбцу для числовых атрибутов. Для строковых атрибутов можно указать наиболее вероятное значение или значение по умолчанию, которое впоследствии может быть соответствующим образом обработано (например, NONAME). Оставлять пустые или фиктивные значения нежелательно: пропущенное значение может заблокировать работу аналитических алгоритмов, а фиктивное (например, $999,999) может быть обработано как истинное.
3. Столбцы должны быть типизированы, то есть содержать данные только одного типа (например, только строковые или только числовые). Кроме того, внутри каждого столбца формат представления чисел или дат должен быть одинаковым. Например, использование в одном столбце краткого (12.07.06) и полного (12 июля 2006 г.) форматов даты способно вызвать серьезные проблемы при загрузке данных. Также нежелательно использовать в одном поле числа в экспоненциальном формате (1,2E + 3) и в обычном (12 000), поскольку это может вызвать проблемы при загрузке значений из данного поля.
4. Строковые значения желательно приводить в соответствие унифицированным шаблонам. Например, нежелательно смешивать представление ФИО, указывая инициалы то справа, то слева от фамилии или вообще не указывая, использовать в инициалах то одну, то две буквы и т.д. При указании названий организаций также нужно использовать единое представление. Например, форма собственности должна во всех строках указываться только после названия (это упростит сортировку названий по алфавиту). Несоблюдение этого требования, скорее всего, не вызовет проблем при загрузке, но может привести к неправильной обработке таких данных аналитическим приложением.
5. Символы-разделители и их количество во всех строках и между столбцами должны быть одинаковыми.
6. Необходимо использовать одинаковые разделители целой и дробной частей чисел и групп разрядов. Например, если по умолчанию в качестве разделителя целой и дробной частей используется точка, а в каком-то значении будет обнаружена запятая, это значение будет рассматриваться системой как строковое.
При загрузке в ХД все эти проблемы автоматически корректируются на этапе ETL. А при непосредственной загрузке пользователю приходится отслеживать эти проблемы самому. Если данных в источнике немного, то они могут быть откорректированы вручную. В противном случае приходится использовать средства очистки данных, предусмотренные в аналитической системе (например, восстановление пропущенных значений, трансформация типов и т.д.).
Чтобы настроить процесс импорта текстового файла с разделителями, обычно требуется указать:
Таким образом, чтобы правильно настроить параметры импорта текстового файла, нужно иметь информацию о файле, которая в большинстве случаев может быть получена только опытным путем. Для этого достаточно открыть файл с помощью текстового редактора, просмотреть структуру файла и при необходимости откорректировать ее (например, присвоить столбцам заголовки).
Текстовые файлы в формате CSV менее известны пользователям, поскольку используются реже, чем обычные TXT-файлы. CSV (от англ. ramma separated values — «значения, разделенные запятыми») — это специальный текстовый формат, предназначенный для представления табличных данных. Каждая строка в таком файле соответствует одной строке таблицы. Значения отдельных столбцов разделяются специальным символом — запятой или точкой с запятой. Используемый символ-разделитель зависит от настроек региональных стандартов. В США это запятая, а в России — точка с запятой, поскольку у нас запятая используется для разделения целой и дробной частей чисел (в отличие от США, где для этого служит точка). Файлы такого типа могут быть получены путем конвертации из любого табличного процессора.
Все свойства обычных текстовых файлов с разделителями, описанные выше, и рекомендации по их подготовке и загрузке в полной мере относятся к CSV-файлам. Но у CSV-файлов есть и ряд преимуществ.
Файлы «плоских» таблиц СУБД семейства dBase, FoxBase, FoxPro и т.д. имеют расширение DBF (database file). Как и файлы любых СУБД, DBF-файлы имеют жестко заданную структуру. В них строго определены имена и типы полей, структура полей и записей, используемые форматы представления данных. Следовательно, проблем с загрузкой данных из таких источников намного меньше по сравнению с текстовыми файлами, поскольку все возможные проблемы контролируются в процессе создания файла. СУБД не позволит присвоить полю некорректное имя, ввести в поле данные, не соответствующие его типу или использующие неправильный разделитель групп разрядов в числе, и т.д., поэтому ожидаемое качество данных, загружаемых из DBF-файлов, является более высоким, чем для текстовых.
При загрузке данных из DBF-файлов в аналитическую систему, как правило, достаточно указать их имя. В некоторых случаях требуется дополнительно указать версию СУБД (dBase III или dBase IV), а также кодовую страницу для корректного отображения символов.
Excel — одно из наиболее популярных офисных приложений, применяемых пользователями всех уровней, поэтому возможность загрузки данных из файлов в формате XLS предусмотрена практически в любой аналитической системе. Однако следует учитывать, что в одном столбце таблицы Excel могут содержаться данные различных типов и форматов, допускаться неправильное использование разделителей целой и дробной частей чисел и групп разрядов в них. В этом плане к ним следует относиться так же внимательно, как и к данным из текстовых файлов.
Файлы реляционных СУБД. Источники этого типа самые «желанные» для пользователей аналитических систем, поскольку с ними меньше всего проблем. Структура данных в файлах реляционных СУБД жестко задана, поля строго типизированы, форматы данных соответствуют стандартам. В большинстве СУБД поддерживается автоматический контроль целостности, непротиворечивости и уникальности данных. Для загрузки данных, например, из файла Access достаточно указать имя файла и таблицу, из которой нужно взять данные.
|
|
 |
