Особенности распределенных транзакций.

Распределенные транзакции выполняются на двух или более серверах, которые называются диспетчерами ресурсов. Управление транзакцией должно координироваться между диспетчерами ресурсов компонентом сервера, который называется диспетчером транзакций. Каждый экземпляр компонента SQL Server Database Engine может действовать как диспетчер ресурсов в распределенных транзакциях, координируемых диспетчерами транзакций, например, координатором распределенных транзакций (Майкрософт) (MS DTC) или другими диспетчерами транзакций, поддерживающими спецификацию Open Group XA обработки распределенных транзакций. Дополнительные сведения см. в документации по MS DTC.

Транзакция в отдельном экземпляре компонента Database Engine, распространяющаяся на несколько данных, в действительности является распределенной транзакцией. Экземпляр управляет распределенной транзакцией на внутреннем уровне, для пользователя она действует как локальная транзакция.

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

Фаза подготовки

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

Фаза фиксации

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

Компонент Database Engine управляет распределенными транзакциями посредством Transact-SQL или API базы данных.

30)Графики запуска транзакций График запуска набора транзакций называется последовательным, если транзакции выполняются строго по очереди, т.е. элементарные операции транзакций не чередуются друг с другом..
Если график запуска набора транзакций содержит чередующиеся элементарные операции транзакций, то такой график называется чередующимся.
При выполнении последовательного графика гарантируется, что транзакции выполняются правильно.
Два графика называются эквивалентными, если при их выполнении будет получен один и тот же результат, независимо от начального состояния базы данных.График запуска транзакции называется верным (сериализуемым), если он эквивалентен какому-либо последовательному графику. График запуска набора транзакций – это последовательность, в которой выполняются элементарные операции заданного набора транзакций. График запуска набора транзакций называется ПОСЛЕДОВАТЕЛЬНЫМ, если транзакции выполняются строго по очереди, т.е. элементарные операции транзакций не чередуются друг с другом.Два графика называются эквивалентными, если при их выполнении и одном и том же начальном состоянии базы будет получен один и тот же результат.Если график набора транзакций содержит чередующиеся элементарные операции, то такой график называется чередующимся.
График запуска транзакций называется верным (сериализуемым), если он эквивалентен
какому-либо последовательному графику.

Триггеры и их роль в СУБД

Триггеры являются одной из разновидностей хранимых процедур. Их исполнение происходит при выполнении для таблицы какого-либо оператора языка манипулирования данными (DML). Триггеры используются для проверки целостности данных, а также для отката транзакций.

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

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

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

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

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

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

3.накопление аудиторской информации посредством фиксации сведений о внесенных изменениях и тех лицах, которые их выполнили;

4.поддержка репликации.

Основной формат команды CREATE TRIGGER показан ниже:

<Определение_триггера>::= CREATE TRIGGER имя_триггера BEFORE | AFTER <триггерное_событие> ON <имя_таблицы> [REFERENCING <список_старых_или_новых_псевдонимов>] [FOR EACH { ROW | STATEMENT}] [WHEN(условие_триггера)] <тело_триггера>

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

Выполняемые триггером действия задаются для каждой строки (FOR EACH ROW), охваченной данным событием, или только один раз для каждого события (FOR EACH STATEMENT).

Обозначение <список_старых_или_новых_псевдонимов> относится к таким компонентам, как старая или новая строка (OLD / NEW) либо старая или новая таблица (OLD TABLE / NEW TABLE). Основное их преимущество заключается в том, что стандартные функции сохраняются внутри базы данных и согласованно активизируются при каждом ее обновлении. Это может существенно упростить приложения. Недостатки:

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

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

Понятие об OLAP.

OLAP (англ. online analytical processing, аналитическая обработка в реальном времени) — технология обработки данных, заключающаяся в подготовке суммарной (агрегированной) информации на основе больших массивов данных, структурированных по многомерному принципу. Причина использования OLAP для обработки запросов — это скорость. Реляционные БД хранят сущности в отдельных таблицах, которые обычно хорошо нормализованы. Эта структура удобна для операционных БД (системы OLTP), но сложные многотабличные запросы в ней выполняются относительно медленно. OLAP-структура, созданная из рабочих данных, называется OLAP-куб. Куб создаётся из соединения таблиц с применением схемы звезды или схемы снежинки. В центре схемы звезды находится таблица фактов, которая содержит ключевые факты, по которым делаются запросы. Множественные таблицы с измерениями присоединены к таблице фактов. Эти таблицы показывают, как могут анализироваться агрегированные реляционные данные. Количество возможных агрегирований определяется количеством способов, которыми первоначальные данные могут быть иерархически отображены. OLAP-куб содержит в себе базовые данные и информацию об измерениях (агрегаты). Куб потенциально содержит всю информацию, которая может потребоваться для ответов на любые запросы. При огромном количестве агрегатов зачастую полный расчёт происходит только для некоторых измерений, для остальных же производится «по требованию». Существуют три типа OLAP 1.многомерная OLAP (Multidimensional OLAP — MOLAP); 2.реляционная OLAP (Relational OLAP — ROLAP); 3.гибридная OLAP (Hybrid OLAP — HOLAP). MOLAP — это классическая форма OLAP, так что её часто называют просто OLAP. Она использует суммирующую БД, специальный вариант процессора пространственных БД и создаёт требуемую пространственную схему данных с сохранением как базовых данных, так и агрегатов.ROLAP работает напрямую с реляционным хранилищем, факты и таблицы с измерениями хранятся в реляционных таблицах, и для хранения агрегатов создаются дополнительные реляционные таблицы.HOLAP использует реляционные таблицы для хранения базовых данных и многомерные таблицы для агрегатов.Особым случаем ROLAP является ROLAP реального времени (Real-time ROLAP — R-ROLAP). В отличие от ROLAP в R-ROLAP для хранения агрегатов не создаются дополнительные реляционные таблицы, а агрегаты рассчитываются в момент запроса. При этом многомерный запрос к OLAP-системе автоматически преобразуется в SQL-запрос к реляционным данным.Каждый тип хранения имеет определённые преимущества, хотя есть разногласия в их оценке у разных производителей. MOLAP лучше всего подходит для небольших наборов данных, он быстро рассчитывает агрегаты и возвращает ответы, но при этом генерируются огромные объёмы данных. ROLAP оценивается как более масштабируемое решение, использующее к тому же наименьшее возможное пространство. При этом скорость обработки значительно снижается. HOLAP находится посреди этих двух подходов, он достаточно хорошо масштабируется и быстро обрабатывается. Архитектура R-ROLAP позволяет производить многомерный анализ OLTP-данных в режиме реального времени.Сложность в применении OLAP состоит в создании запросов, выборе базовых данных и разработке схемы, в результате чего большинство современных продуктов OLAP поставляются вместе с огромным количеством предварительно настроенных запросов. Другая проблема — в базовых данных. Они должны быть полными и непротиворечивыми. Реализации OLAP Исторически первой многомерной системой управления базами данных, по существу являющейся OLAP-реализацией, считается система Express, разработанная в 1970году компанией IRI (позднее права на продукт были приобретены корпорацией Oracle и превращён в OLAP-опцию для Oracle Database). Термин OLAP ввёл Эдгар Кодд.С точки зрения реализации делятся на «физическую OLAP» и «виртуальную» (реляционную, англ. Relational OLAP, ROLAP). «Физическая», в свою очередь, в зависимости от реализации подразделяется на многомерную (англ. Multidimensional OLAP, MOLAP) и гибридную — (англ. Hybrid OLAP, HOLAP).В первом случае наличествует программа, выполняющая на этапе предварительной загрузки данных в OLAP из источников предварительный расчёт агрегатов (вычислений по нескольким исходным значениям, например «итог за месяц»), которые затем сохраняются в специальную многомерную базу данных, обеспечивающую быстрое извлечение и экономичное хранение.Гибридная реализация является комбинацией: сами данные хранятся в реляционной базе данных, а агрегаты — в многомерной.В ROLAP-реализациях все данные хранятся и обрабатываются реляционных системах управления базами данных, а агрегаты могут не существовать вообще или создаваться по первому запросу в СУБД или кэше аналитического программного обеспечения.

 

33)Управление параллелизмом с помощью временных меток. Метод временных меток Альтернативный метод сериализации транзакций, хорошо работающий в условиях редких конфликтов транзакций и не требующий построения графа ожидания транзакций основан на использовании временных меток. Основная идея метода состоит в следующем: если транзакция A началась раньше транзакции B, то система обеспечивает такой режим выполнения, как если бы A была целиком выполнена до начала B. Для этого каждой транзакции T предписывается временная метка t, соответствующая времени начала T. При выполнении операции над объектом r базы данных транзакция T помечает его своей временной меткой и типом операции (чтение или изменение). Перед выполнением операции над объектом r транзакция B выполняет следующие действия: 1.Проверяет, не закончилась ли транзакция A, пометившая этот объект. Если A закончилась, B помечает объект r своей временной меткой и выполняет операцию. 2.Если транзакция A не завершилась, то B проверяет конфликтность операций. Если операции неконфликтны, при объекте r остается или проставляется временная метка с меньшим значением (более ранняя), и транзакция B выполняет свою операцию. 3.Если операции B и A конфликтуют, то если t(A) > t(B) (т.е. транзакция A является более "молодой", чем B), то транзакция A откатывается и, получив новую временную метку, начинается заново. Транзакция B продолжает работу. 4.Если же t(A) < t(B) (A "старше" B), то транзакция B откатывается и, получив новую временную метку, начинается заново. Транзакция A продолжает работу. В итоге система обеспечивает такую работу, при которой при возникновении конфликтов всегда откатывается более молодая транзакция (начавшаяся позже). Очевидным недостатком метода временных меток является то, что может откатиться более дорогая транзакция, начавшаяся позже более дешевой. К другим недостаткам метода временных меток относятся потенциально более частые откаты транзакций, чем в случае использования блокировок. Это связано с тем, что конфликтность транзакций определяется более грубо.

34)Управление параллелизмом с помощью представления копий данных Изменение данных пользователями может оказывать влияние на других пользователей, считывающих или изменяющих эти же данные в этот же момент времени. В этом случае говорят, что пользователи получают параллельный доступ к этим данным. Если в системе хранения данных отсутствует управление параллелизмом, то могут наблюдаться следующие побочные эффекты. 1.Потерянные обновления 2.Незафиксированная зависимость («грязное» чтение) 3.Анализ несогласованности (неповторяющееся чтение) 4.Фантомные операции чтения 5.Отсутствующие или дублированные операции чтения, вызванные обновлениями строк Потерянные обновления возникают, когда две или более транзакций выбирают одну и ту же строку и изменяют ее на основании ее исходного значения. Каждая транзакция не знает о других транзакциях. Последнее обновление изменяет данные других транзакций, что приводит к потере данных. Например, у двух редакторов есть электронные копии одного и того же документа. Каждый редактор изменяет свою копию независимо и затем сохраняет ее, перезаписывая исходный документ. Редактор, сохраняющий свою измененную копию, перезаписывает изменения, сделанные другим редактором. Этой проблемы можно избежать, если у одного редактора не будет доступа к этому файлу до завершения и фиксации транзакции другого редактора.

Незафиксированная зависимость («грязное» чтение) Незафиксированная зависимость возникает, когда вторая транзакция выбирает строку, изменяемую в данный момент другой транзакцией. Вторая транзакция будет считывать данные, которые еще не зафиксированы и могут быть изменены первой транзакцией.

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

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

Отсутствующие или дублированные операции чтения, вызванные обновлениями строк 1.Исчезновение обновленной строки или ее многократное отображение
Транзакции, работающие на уровне изоляции READ UNCOMMITTED, не используют совмещаемые блокировки, чтобы предотвратить изменение считываемых текущей транзакцией данных другими транзакциями. Транзакции, работающие на уровне изоляции READ COMMITTED, используют совмещаемые блокировки, однако блокировки строк и страниц снимаются после чтения строки. В любом случае, если во время сканирования индекса другой пользователь изменит ключевой столбец индекса для строки, считывание которой происходит в данный момент, причем строка была перемещена в позицию, до которой операция сканирования еще не дошла, эта строка может появиться повторно. Аналогично, если изменение ключа переместило строку в позицию, считывание которой уже прошло, то она может не отобразиться. Чтобы избежать этого, воспользуйтесь подсказками SERIALIZABLE или HOLDLOCK либо управлением версиями строк. Дополнительные сведения см. в разделах Табличные подсказки (Transact-SQL) и Уровни изоляции, основанные на управлении версиями строк, в компоненте Database Engine. 2.Отсутствие одной или нескольких строк, которые не подвергались обновлению
Пропажа строк может возникнуть в случае, если при использовании уровня READ UNCOMMITTED запрос читает строки в порядке их расположения (с использованием IAM-страниц), а другая транзакция вызывает разбиение страницы. Этого не может произойти при использовании уровня изоляции READ COMMITTED, поскольку во время разбиения страницы включается блокировка таблицы. Также этого не может произойти, если таблица не имеет кластеризованного индекса, поскольку в таком случае обновления не вызывают разбиения страниц.

35)Задачи, возникающие при переносе данных из ОИД (оперативных источников данных) в хранилище данных Все данные в ХД делятся на три основные категории □ детальные данные; □ агрегированные данные; □ метаданные. детальными являются данные, переносимые непосредственно из ОИД. Они соответствуют элементарным событиям, фиксируемым OLTP-системами (на­пример, продажи, эксперименты и др.). Принято разделять все данные на из­мерения и факты. Измерениями называются наборы данных, необходимые для описания событий (например, города, товары, люди и т. п.). Фактами на­зываются данные, отражающие сущность события (например, количество проданного товара, результаты экспериментов и т. п.). Фактические данные могут быть представлены в виде числовых или категориальных значений.В процессе эксплуатации ХД необходимость в ряде детальных данных может снизиться. Ненужные детальные данные могут храниться в архивах в сжатом виде на более емких накопителях с более медленным доступом (например, на магнитных лентах). Данные в архиве остаются доступными для обработки и анализа. Регулярно используемые для анализа данные должны храниться нанакопителях с быстрым доступом (например, на жестких дисках).На основании детальных данных могут быть получены агрегированные (обобщенные) данные. Агрегирование происходит путем суммирования чи­словых фактических данных по определенным измерениям. В зависимости от возможности агрегировать данные они подразделяются на следующие типы:

□ аддитивные —числовые фактические данные, которые могут быть просуммированы по всем измерениям;

□ полуаддитивные — числовые фактические данные, которые могут быть просуммированы только по определенным измерениям;

□ неаддитивные — фактические данные, которые не могут быть просуммированы ни по одному измерению.

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

Для удобства работы с ХД необходима информация о содержащихся в нем данных. Такая информация называется метаданными (данные о данных). Со­гласно концепции Захмана метаданные должны отвечать на следующие во­просы — что, кто, где, как, когда и почему: □ что (описание объектов) метаданные описывают объекты предметной области, информация о которых хранится в ХД. Такое описание включает: атрибуты объектов, их возможные значения, соответствующие поля в ин­формационных структурах ХД, источники информации об объектах и т. п.; □ кто (описание пользователей) — метаданные описывают категории поль­зователей, использующих данные. Они описывают права доступа к дан­ным, а также включают в себя сведения о пользователях, выполнявших над данными различные операции (ввод, редактирование, загрузку, извле­чение и т. п.); □ где (описание места хранения) — метаданные описывают местоположение серверов, рабочих станций, ОИД, размещенные на них программные сред­ства и распределение между ними данных; □ как (описание действий)— метаданные описывают действия, выполняе­мые над данными. Описываемые действия могли выполняться как в про­цессе переноса из ОИД (например, исправление ошибок, расщепление по­лей и т. п.), так и в процессе их эксплуатации в ХД; □ когда (описание времени) — метаданные описывают время выполнения разных операций над данными (например, загрузка, агрегирование, архи­
вирование, извлечение и т. п.); □ почему (описание причин) — метаданные описывают причины, повлек­шие выполнение над данными тех или иных операций. Такими причинами могут быть требования пользователей, статистика обращений к данным и т. п. Так как метаданные играют важную роль в процессе работы с ХД, то к ним должен быть обеспечен удобный доступ. Для этого они сохраняются в репо-зитории метаданных с удобным для пользователя интерфейсом. Данные, поступающие из ОИД в ХД, перемещаемые внутри ХД и поступаю­щие из ХД к аналитикам, образуют следующие информационные потоки:□ входной поток (Inflow)— образуется данными, копируемыми из ОИД вХД; □ поток обобщения (Upflow)— образуется агрегированием детальных дан­ных и их сохранением в ХД; □ архивный поток (Downflow) — образуется перемещением детальных дан­ных, количество обращений к которым снизилось; □ поток метаданных (MetaFlow) — образуется потоком информации о дан­ных в репозиторий данных; □ выходной поток (Outflow) — образуется данными, извлекаемыми пользо­вателями; □ обратный поток (Feedback Flow) — образуется очищенными данными, за­писываемыми обратно в ОИД. Самый мощный из информационных потоков — входной — связан с перено­сом данных из ОИД. Обычно информация не просто копируется в ХД, а под­вергается обработке: данные очищаются и обогащаются за счет добавления новых атрибутов. Исходные данные из ОИД объединяются с информацией из внешних источников — текстовых файлов, сообщений электронной почты, электронных таблиц и др. При разработке ХД не менее 60 % всех затрат свя­зано с переносом данных. Процесс переноса, включающий в себя этапы извлечения, преобразования и загрузки, называют ETL-процессом (Е — extraction, Т — transformation, L — loading: извлечение, преобразование и загрузка, соответственно). Программ­ные средства, обеспечивающие его выполнение, называются ETL-системами. Традиционно ETL-системы использовались для переноса информации из устаревших версий информационных систем в новые. В настоящее время ETL-процесс находит все большее применение для переноса данных из ОИД в ХД и ВД.

Рассмотрим более подробно этапы ETL-процесса Извлечение данных — чтобы начать ETL-процесс, необходимо извлечь данные из одного или нескольких источников и подготовить их к этапу пре­образования. Можно выделить два способа извлечения данных:

1. Извлечение данных вспомогательными программными средствами непо­средственно из структур хранения информации (файлов, электронных таблиц, БД и т. п. Достоинствами такого способа извлечения данных явля­ются: · отсутствие необходимости расширять OLTP-систему (это особенно важно, если ее структура закрыта); · данные могут извлекаться с учетом потребностей процесса переноса. 2. Выгрузка данных средствами OLTP-систем в промежуточные структуры. Достоинствами такого подхода являются: 1. возможность использовать средства OLTP-систем, адаптированные к структурам данных; 2.средства выгрузки изменяются вместе с изменениями OLTP-систем и ОИД; 3 возможность выполнения первого шага преобразования данных за счет определенного формата промежуточной структуры хранения данных. Преобразование данных — после того как сбор данных завершен, необхо­димо преобразовать их для размещения на новом месте. На этом этапе вы­полняются следующие процедуры: □ обобщение данных (aggregation) — перед загрузкой данные обобщаются. Процедура обобщения заменяет многочисленные детальные данные отно­сительно небольшим числом агрегированных данных. Например, предпо­ложим, что данные о продажах за год занимают в нормализованной базе

данных несколько тысяч записей. После обобщения данные преобразуют­ся в меньшее число кратких записей, которые будут перенесены в ХД; □ перевод значений (value translation)— в ОИД данные часто хранятся в за­кодированном виде для того, чтобы сократить избыточность данных и па­мять для их хранения. Например, названия товаров, городов, специально­стей и т. п. могут храниться в сокращенном виде. Поскольку ХД содержат обобщенную информацию и рассчитаны на простое использование, зако­дированные данные обычно заменяют на более понятные описания; □ создание полей (field derivation) — при создании полей для конечных пользователей создается и новая информация. Например, ОИД содержит одно поле для указания количества проданных товаров, а второе — для указания цены одного экземпляра. Для исключения операции вычисления стоимости всех товаров можно создать специальное поле для ее хранения во время преобразования данных; □ очистка данных (cleaning) — направлена на выявление и удаление ошибок и несоответствий в данных с целью улучшения их качества. Проблемы с качеством встречаются в отдельных ОИД, например, в файлах и БД могут быть ошибки при вводе, отдельная информация может быть утрачена, мо­гут присутствовать "загрязнения" данных и др. Очистка также применяет­ся для согласования атрибутов полей таким образом, чтобы они соответст­вовали атрибутам базы данных назначения. Загрузка данных — после того как данные преобразованы для размещения в ХД, осуществляется этап их загрузки. При загрузке выполняется запись преобразованных детальных и агрегированных данных. Кроме того, при записи новых детальных данных часть старых может переноситься в архив.