Преобразование реляционной базы данных OLTP к модели организации хранилищ данных
Способ решить это на самом деле легко. Я использовал этот код, чтобы заставить его работать.
SELECT tecnico_id, COUNT(tecnico_id) as cantidad_tecnico ,
SUM(TIMESTAMPDIFF(MINUTE,convert(time_at,time),convert(visit_hour_in, time))) as tiempo,
(TIMESTAMPDIFF(MINUTE,convert(time_at,time),convert(visit_hour_in, time))/COUNT(tecnico_id)) as promedio
FROM ticket group by tecnico_id asc
4 ответа
Лично я работаю следующим образом:
- Сначала спроектируйте хранилище данных. В частности, проектируйте таблицы, которые необходимы как часть DW, игнорируя любые промежуточные таблицы.
- Проектируйте ETL, используя SSIS, но иногда с SSIS, вызывающим хранимые процедуры в задействованных базах данных.
- Если какие-либо промежуточные таблицы являются требуется как часть ETL, хорошо, но в то же время убедитесь, что они очищены. Промежуточная таблица, используемая только как часть одной серии шагов ETL, должна быть усечена после завершения этих шагов, с успехом или безуспешно.
- У меня есть пакеты SSIS, которые ссылаются на базу данных OLTP, по крайней мере, для извлечения данных в промежуточные таблицы , В зависимости от ситуации они могут обрабатывать таблицы OLTP непосредственно в хранилище данных. Все такие запросы выполняются WITH (NOLOCK).
- Document, Document, Document. Дайте понять, какие входные данные используются каждым пакетом и куда направляются выходные данные. Обязательно задокументируйте критерии, по которым выбираются входные данные (последние 24 часа? С момента последнего успеха? Новые значения идентификаторов? Все строки?)
Это сработало для меня, хотя я признаю, что не делал многих из них проектов, ни каких-либо действительно крупных.
В настоящее время я работаю над небольшим / средним информационным центром. Мы принимаем некоторые концепции, выдвинутые Кимбаллом, то есть звездную схему с таблицами фактов и измерений. Мы структурируем его так, чтобы факты присоединялись только к измерениям (не факт к факту или измерение к измерению - но это наш выбор, а не то, как это должно быть сделано), поэтому мы сглаживаем все соединения измерений в таблицу фактов.
Мы используем SSIS для перемещения данных из производственной БД -> исходной БД -> промежуточной БД -> отчетной БД (возможно, мы могли бы использовать меньше БД, но так оно и случилось).
SSIS действительно хорош, поскольку позволяет очень логично структурировать потоки данных. Мы используем комбинацию компонентов SSIS и хранимых процедур, где одна приятная особенность SSIS - это возможность предоставлять команды SQL в качестве преобразования между исходным и целевым потоком данных. Это означает, что мы можем при желании вызывать сохраненные процедуры для каждой строки, что может быть полезно (хотя и немного медленнее).
Мы также используем новую функцию SQL Server 2008, называемую системой отслеживания измененных данных (CDC), которая позволяет вам контролировать все изменения в таблице (вы можете указать, какие столбцы вы хотите просматривать в этих таблицах), поэтому мы используем это в производственной БД, чтобы сообщить, что изменилось, чтобы мы могли перемещать только эти записи в исходную БД для обработки.
Объяснение процесса Джона Сондерса является хорошим.
Если вы хотите реализовать проект хранилища данных на SQL Server, вы найдете всю информацию, необходимую для реализации всего проекта, в прекрасном тексте « Набор инструментов Microsoft Data Warehouse ».
Как ни странно, одним из авторов является Ральф Кимбалл: -)
Вы можете ознакомиться с Data Vault Modeling . Он утверждает, что решает некоторые более отдаленные проблемы, такие как изменение атрибутов.