OBIEE - Схема

Схема - это логическое описание всей базы данных. Он включает имя и описание записей всех типов, включая все связанные элементы данных и агрегаты. Как и база данных, DW также требует поддержки схемы. База данных использует реляционную модель, в то время как DW использует схемы Star, Snowflake и Fact Constellation (схема Galaxy).

Схема звезды

В звездообразной схеме есть несколько таблиц измерений в ненормализованной форме, которые объединены только с одной таблицей фактов. Эти таблицы логически объединены для удовлетворения некоторых бизнес-требований в целях анализа. Эти схемы представляют собой многомерные структуры, которые используются для создания отчетов с помощью инструментов отчетности BI.

Измерения в схемах Star содержат набор атрибутов, а таблицы фактов содержат внешние ключи для всех измерений и значений измерений.

В приведенной выше звездообразной схеме в центре есть таблица фактов «Факты продаж», которая соединена с 4 таблицами измерений с использованием первичных ключей. Таблицы измерений не подвергаются дальнейшей нормализации, и такое объединение таблиц известно как звездообразная схема в DW.

Таблица фактов также содержит значения показателей - dollar_sold и units_sold.

Схема снежинок

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

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

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

Гранулярность

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

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

Процесс определения степени детализации состоит из двух этапов:

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

Медленно меняющиеся размеры

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

пример

Энди является сотрудником XYZ Inc. Он впервые оказался в Нью-Йорке в июле 2015 года. Исходная запись в таблице поиска сотрудников имеет следующую запись:

ID сотрудника	10001
имя	Энди
Расположение	Нью-Йорк

Позже он переехал в Лос-Анджелес, Калифорния. Как XYZ Inc. теперь следует изменить таблицу сотрудников, чтобы отразить это изменение?

Это известно как концепция «медленно меняющегося измерения».

Есть три способа решить этот тип проблемы:

Решение 1

Новая запись заменяет исходную. Никаких следов старой записи не существует.

Медленно меняя размер, новая информация просто заменяет исходную. Другими словами, история не ведется.

ID сотрудника	10001
имя	Энди
Расположение	Лос-Анджелес, Калифорния

Benefit - Это самый простой способ справиться с проблемой медленно меняющегося размера, поскольку нет необходимости отслеживать старую информацию.
Disadvantage - Вся историческая информация потеряна.
Use - Решение 1 следует использовать, когда DW не требуется отслеживать историческую информацию.

Решение 2

Новая запись вводится в таблицу измерения «Сотрудник». Итак, с сотрудником Энди обращаются как с двумя людьми.

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

ID сотрудника	10001	10002
имя	Энди	Энди
Расположение	Нью-Йорк	Лос-Анджелес, Калифорния

Benefit - Этот метод позволяет нам хранить всю историческую информацию.
Disadvantage- Размер стола растет быстрее. Когда количество строк в таблице очень велико, пространство и производительность таблицы могут быть проблемой.
Use - Решение 2 следует использовать, когда DW необходимо хранить исторические данные.

Решение 3

Исходная запись в измерении "Сотрудник" изменяется, чтобы отразить это изменение.

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

ID сотрудника	имя	Исходное местоположение	Новое место	Дата перемещения
10001	Энди	Нью-Йорк	Лос-Анджелес, Калифорния	Июль 2015 г.

Benefits- Это не увеличивает размер таблицы, поскольку обновляется новая информация. Это позволяет нам хранить историческую информацию.
Disadvantage - Этот метод не сохраняет всю историю, когда значение атрибута изменяется более одного раза.
Use - Решение 3 следует использовать только тогда, когда от DW требуется хранить информацию об исторических изменениях.

Нормализация

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

Цель нормализации

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

Преимущества

Целостность данных.
Повышает согласованность данных.
Уменьшает избыточность данных и необходимое пространство.
Снижает стоимость обновления.
Максимальная гибкость при ответе на специальные запросы.
Уменьшает общее количество строк в блоке.

Недостатки

Низкая производительность запросов в базе данных из-за того, что для получения соответствующих данных из нескольких нормализованных таблиц необходимо выполнять соединения.

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

пример

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