Что лучший подход должен получить от реляционной базы данных OLTP до куба OLAP?
Перейдите в Инструменты - Параметры - Текстовый редактор - Все языки - Общие и отметьте номера строк, чтобы показать номера строк для всех файлов.
Если вы просто хотите увидеть (или не увидеть) номера строк определенного файла, вы можете переопределить эту глобальную настройку, перейдя на страницу Текстовый редактор - - Общие.
2 ответа
Да, это основная идея. Вы берете свою сильно нормализованную базу данных OLTP и денормализуете ее в кубы с целью разрезания и нарезания данных, а затем представления отчетов по ним. Техника логического проектирования называется размерным моделированием. В Kimball Group имеется тонна полезной информации о размерном моделировании . Книги Ральфа Кимбалла по этой теме также превосходны. Если вы хотите узнать больше о самих инструментах бизнес-аналитики, посетите виртуальные лаборатории по SSIS, службам анализа и многому другому.
Ответ: да, но.
Измерение в SSAS имеет отношения между атрибутами, которые могут использоваться в виде серии полей для фильтрации среза. Эти отношения могут быть иерархическими (более одного уровня - один атрибут может иметь родительский и дочерний элементы. Вы также можете установить пути детализации (называемые иерархиями в SSAS), которые действуют как атрибуты, но имеют управляемую развертку.
для этого вам необходимо иметь в базе данных ключи, которые находятся в строго иерархических отношениях (т.е. ключи не могут иметь нечетких отношений, когда у дочернего элемента может быть более одного родителя). Обратите внимание, что это не вся история, но это на данный момент достаточно близки к реальности.
Эти иерархии могут быть построены системой из плоской структуры данных или представлены в виде снежинки со связями, размеченными в базовом представлении источника данных (DSV являются частью метаданных куба и могут
Снежинка - это схема в стиле 3NF (она не обязательно должна быть 3NF - на практике вы можете сгладить ее части), которая имеет только 1: Отношения M. SSAS может поддерживать несколько другие структуры измерений, такие как родитель-потомок (отношения родитель-потомок с рекурсивным самосоединением) и измерения M: M (отношения M: M - именно так они звучат). Размеры этого типа более сложны, но могут быть вам полезны.
Если у вас есть ключи в исходных данных, которые могут иметь семантику данных, эквивалентную снежинке, вы можете заполнить куб с помощью серии представлений базы данных в исходной системе, которые представляют базовые данные в достаточно похожем на снежинку формат для использования в измерениях куба (на самом деле я делал это пару раз). Схемы, в которых интенсивно используются синтетические ключи, с большей вероятностью подойдут для этого.
Если ваш поставщик или другие стороны не разрешают вам добавлять представления в исходную базу данных, вы можете вместо этого использовать представление источника данных. В DSV могут быть виртуальные таблицы, называемые «именованными запросами», которые заполняются из запроса к базе данных.
Таблицы фактов присоединяются к измерениям. В SSAS2005 + вы можете объединять разные таблицы фактов на разных уровнях измерения. Обычно я не особо использовал бы это в хранилище данных, но эта функция может быть полезна, если вы пытаетесь использовать исходные данные без необходимости слишком сильно их массировать.
Если это не сработает, возможно, вам придется написать процесс ETL для заполнения схемы звезды или снежинки.
Несколько оговорок:
Кубы можно заставить работать в режиме реального времени, когда они просто отправляют запрос к базовым данным. Это имеет некоторый риск создания неэффективных запросов к вашим исходным данным, поэтому не рекомендуется, если вы действительно не уверены, что знаете, что делаете.
Что касается (i), вы, вероятно, не сможете использовать кубы в качестве источника данных для экранов в вашем приложении.Если вам нужно рассчитать средние значения для чего-то, что пользователь хочет видеть на экране, вам, вероятно, придется рассчитать это в хранимой процедуре за экраном.
Если вы это сделаете, настройте реплицированную базу данных и заполните куб из нее. Периодически обновляйте эту базу данных, чтобы ваш процесс ETL мог работать с внутренне согласованным набором данных. Если вы запускаете действующую базу данных, вы рискуете, что некоторые элементы будут заполнены позже, поскольку это зависит от записей, которые были созданы после запуска соответствующего процесса.
Может возникнуть ситуация, когда вы запускаете загрузку измерения, а затем в систему вводятся новые данные. Когда запускается загрузка таблицы фактов, она теперь содержит данные, зависящие от данных измерения, которые не были загружены. Это сломает куб и вызовет сбой процесса загрузки. Пакетное обновление реплицированной базы данных для запуска ETL или загрузки куба смягчит эту проблему.
Если у вас нет возможности реплицировать базу данных, вы можете настроить дополнительные политики резервирования для отсутствующих данных.Если ваши базовые производственные данные содержат значительные проблемы с качеством данных, они будут отражены в кубах. GIGO.