Схема представляет собой логическое описание всей базы данных. Он включает в себя имя и описание записей всех типов, включая все связанные элементы данных и агрегаты. Как и база данных, DW также требует поддержки схемы. База данных использует реляционную модель, в то время как DW использует схемы Star, Snowflake и Fact Constellation (схема Galaxy).
Схема звезды
В схеме «звезда» существует несколько таблиц измерений в ненормализованной форме, которые объединяются только в одну таблицу фактов. Эти таблицы объединены в логическом порядке, чтобы удовлетворить некоторые бизнес-требования для целей анализа. Эти схемы являются многомерными структурами, которые используются для создания отчетов с использованием инструментов отчетности BI.
Измерения в схемах Star содержат набор атрибутов, а таблицы Fact содержат внешние ключи для всех измерений и значений измерений.
В приведенной выше схеме «звезда» в центре находится таблица фактов «Факт продаж», которая соединяется с 4 таблицами измерений с использованием первичных ключей. Таблицы измерений больше не нормализуются, и это объединение таблиц известно как схема звезды в DW.
Таблица фактов также содержит значения мер — dollar_sold и units_sold.
Схема снежинок
В схеме «Снежинки» есть несколько таблиц измерений в нормализованной форме, которые объединены только в одну таблицу фактов. Эти таблицы объединены в логическом порядке, чтобы удовлетворить некоторые бизнес-требования для целей анализа.
Единственная разница между схемой Star и Snowflakes заключается в том, что таблицы измерений дополнительно нормализованы. Нормализация разбивает данные на дополнительные таблицы. Из-за нормализации в схеме Snowflake избыточность данных уменьшается без потери какой-либо информации, и, следовательно, становится проще в обслуживании и экономит место для хранения.
В приведенном выше примере со схемой Snowflakes таблица Product и Customer дополнительно нормализуется для экономии места на диске. Иногда он также обеспечивает оптимизацию производительности при выполнении запроса, который требует обработки строк непосредственно в нормализованной таблице, поэтому он не обрабатывает строки в первичной таблице измерений и попадает непосредственно в нормализованную таблицу в схеме.
Зернистость
Гранулярность в таблице представляет уровень информации, хранящейся в таблице. Высокая степень детализации данных означает, что данные находятся на уровне транзакций или около него, что более детально. Низкая степень детализации означает, что данные имеют низкий уровень информации.
Таблица фактов обычно разрабатывается с низкой степенью детализации. Это означает, что нам нужно найти самый низкий уровень информации, которая может быть сохранена в таблице фактов. В измерении даты уровень детализации может быть годом, месяцем, кварталом, периодом, неделей и днем.
Процесс определения гранулярности состоит из двух этапов:
- Определение размеров, которые должны быть включены.
- Определение местоположения для размещения иерархии каждого измерения информации.
Медленно меняющиеся размеры
Медленно меняющиеся измерения относятся к изменению значения атрибута с течением времени. Это одна из общих концепций в DW.
пример
Энди является сотрудником XYZ Inc. Впервые он был расположен в Нью-Йорке в июле 2015 года. Оригинальная запись в таблице поиска сотрудников содержит следующую запись:
| ID сотрудника | 10001 |
|---|---|
| название | Энди |
| Место нахождения | Нью-Йорк |
Позднее он переехал в Лос-Анджелес, штат Калифорния. Как теперь XYZ Inc. может изменить свою таблицу сотрудников, чтобы отразить это изменение?
Это известно как концепция «медленно меняющихся размеров».
Есть три способа решения этой проблемы:
Решение 1
Новая запись заменяет оригинальную запись. Никаких следов старой записи не существует.
Медленно меняя размер, новая информация просто перезаписывает исходную информацию. Другими словами, история не сохраняется.
| ID сотрудника | 10001 |
|---|---|
| название | Энди |
| Место нахождения | Лос-Анджелес, Калифорния |
-
Преимущество — это самый простой способ справиться с проблемой медленно меняющегося измерения, так как нет необходимости отслеживать старую информацию.
-
Недостаток — вся историческая информация потеряна.
-
Использование — Решение 1 следует использовать, когда DW не требуется отслеживать историческую информацию.
Преимущество — это самый простой способ справиться с проблемой медленно меняющегося измерения, так как нет необходимости отслеживать старую информацию.
Недостаток — вся историческая информация потеряна.
Использование — Решение 1 следует использовать, когда DW не требуется отслеживать историческую информацию.
Решение 2
Новая запись вводится в таблицу измерений Employee. Так что с сотрудником Энди обращаются как с двумя людьми.
Новая запись добавляется в таблицу для представления новой информации, и будут присутствовать как исходная, так и новая запись. Новая запись получает свой первичный ключ следующим образом:
| ID сотрудника | 10001 | 10002 |
|---|---|---|
| название | Энди | Энди |
| Место нахождения | Нью-Йорк | Лос-Анджелес, Калифорния |
-
Преимущество — этот метод позволяет нам хранить всю историческую информацию.
-
Недостаток — размер стола растет быстрее. Когда количество строк в таблице очень велико, проблема может быть связана с пространством и производительностью таблицы.
-
Использование — Решение 2 следует использовать, когда необходимо, чтобы DW сохранил исторические данные.
Преимущество — этот метод позволяет нам хранить всю историческую информацию.
Недостаток — размер стола растет быстрее. Когда количество строк в таблице очень велико, проблема может быть связана с пространством и производительностью таблицы.
Использование — Решение 2 следует использовать, когда необходимо, чтобы DW сохранил исторические данные.
Решение 3
Исходная запись в измерении Employee изменяется, чтобы отразить это изменение.
Там будет два столбца, чтобы указать конкретный атрибут, один указывает исходное значение, а другой указывает новое значение. Там также будет столбец, который указывает, когда текущее значение становится активным.
| ID сотрудника | название | Исходное местоположение | Новое место | Дата перенесена |
|---|---|---|---|---|
| 10001 | Энди | Нью-Йорк | Лос-Анджелес, Калифорния | Июль 2015 |
-
Преимущества — это не увеличивает размер таблицы, поскольку обновляется новая информация. Это позволяет нам хранить историческую информацию.
-
Недостаток — этот метод не сохраняет всю историю, когда значение атрибута изменяется более одного раза.
-
Использование. Решение 3 следует использовать только в том случае, если DW обязано хранить информацию об исторических изменениях.
Преимущества — это не увеличивает размер таблицы, поскольку обновляется новая информация. Это позволяет нам хранить историческую информацию.
Недостаток — этот метод не сохраняет всю историю, когда значение атрибута изменяется более одного раза.
Использование. Решение 3 следует использовать только в том случае, если DW обязано хранить информацию об исторических изменениях.
нормализация
Нормализация — это процесс разложения таблицы на менее избыточные меньшие таблицы без потери какой-либо информации. Таким образом, нормализация базы данных — это процесс организации атрибутов и таблиц базы данных для минимизации избыточности данных (дублирование данных).
Цель нормализации
-
Он используется для устранения определенных типов данных (избыточность / репликация) для улучшения согласованности.
-
Он обеспечивает максимальную гибкость для удовлетворения будущих информационных потребностей, сохраняя таблицы, соответствующие типам объектов, в их упрощенных формах.
-
Он производит более четкую и удобочитаемую модель данных.
Он используется для устранения определенных типов данных (избыточность / репликация) для улучшения согласованности.
Он обеспечивает максимальную гибкость для удовлетворения будущих информационных потребностей, сохраняя таблицы, соответствующие типам объектов, в их упрощенных формах.
Он производит более четкую и удобочитаемую модель данных.
преимущества
- Целостность данных.
- Улучшает согласованность данных.
- Уменьшает избыточность данных и необходимое пространство.
- Уменьшает стоимость обновления.
- Максимальная гибкость при ответе на специальные запросы.
- Уменьшает общее количество строк на блок.
Недостатки
Низкая производительность запросов в базе данных, потому что соединения должны выполняться для получения соответствующих данных из нескольких нормализованных таблиц.
Вы должны понимать модель данных, чтобы выполнить правильные объединения между несколькими таблицами.
пример
В приведенном выше примере таблица внутри зеленого блока представляет собой нормализованную таблицу таблицы внутри красного блока. Таблица в зеленом блоке является менее избыточной, а также с меньшим количеством строк без потери какой-либо информации.