Реляционные и размерные базы данных, какая разница?

Я пытаюсь узнать о OLAP и хранилище данных, и я смущен различием между реляционным и размерным моделированием. Является ли размерное моделирование главным образом реляционным моделированием, но с учетом избыточных/ненормированных данных?

Например, скажем, у меня есть данные по историческим продажам (товар, город, # продажа). Я понимаю, что следующая реляционная точка зрения:

Product | City | # Sales
Apples, San Francisco, 400
Apples, Boston, 700
Apples, Seattle, 600
Oranges, San Francisco, 550
Oranges, Boston, 500
Oranges, Seattle, 600

В то время как следующая более подробная точка зрения:

Product | San Francisco | Boston | Seattle
Apples, 400, 700, 600
Oranges, 550, 500, 600

Но похоже, что обе точки зрения будут, тем не менее, реализованы в идентичной звездной схеме:

Fact table: Product ID, Region ID, # Sales
Product dimension: Product ID, Product Name
City dimension: City ID, City Name

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

City dimension: City ID, City Name, Region ID
Region dimension: Region ID, Region Name, Region Manager, # Regional Stores

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

City dimension: City ID, City Name, Region Name, Region Manager, # Regional Stores

Правильно ли это?

Ответ 1

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

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

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

Замечание относительно OLTP и OLAP имеет здесь значение. Обновление аномалий будет иметь разные последствия для производительности и/или сложности программирования в этих двух ситуациях.

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

Так же, как отступление от вашего вопроса, я однажды построил звездообразную схему как промежуточный шаг между базой данных OLTP, поддерживающей приложение на основе транзакций и datacube внутри Cognos PowerPlay. Используя стандартные методы ETL, комбинированный перенос из базы данных OLTP в звездную схему, а затем из схемы звезд в куб данных фактически превосходил прямую передачу из базы данных OLTP в файл данных. Это был неожиданный результат.

Надеюсь, это поможет.

Ответ 2

Простыми словами нормализованная база данных OLTP разработана с наиболее оптимальной "транзакционной" точкой зрения. Базы данных нормализуются для оптимальной работы с транзакционной системой. Когда я говорю об оптимизации транзакционной системы, я имею в виду. Записываю в состояние проектирования структуры базы данных, где все транзакционные операции, такие как удаление, вставка, обновление и выбор, сбалансированы, чтобы обеспечить равное или оптимальное значение для всех из них в любой момент времени.. Они одинаково ценятся в транзакционной системе.

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

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

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

все внешние ключи одно место Факт -не измерение размерного соединения (т.е. мастер для мастер-соединения в таблице). Снежинка представляет собой то же измерение
- Идеально спроектированные факты содержат только числа. меры или внешние ключи. Размер
- используется для описания описания и неагрессивной информации
- избыточность данных игнорируется... но в редких случаях, если сами размеры слишком сильно растут. Конструкция snowflake рассматривается как опция... но это все еще можно избежать

Подробнее читайте в книгах по этой теме.

Ответ 3

Недавно я прочитал разницу между Dimensional и Relational Data Modeling, поскольку мы в основном используем модели Relational в моем бизнесе, где мы храним Enterprise Data Warehouse (EDW).

Согласно Стиву Хоберману в его книге "Моделирование данных сделано просто", различие между двумя типами моделей таково:

Модели реляционных данных фиксируют бизнес-решение о том, как работает часть бизнеса, бизнес-процесс a.k.a
Модели с размерными данными фиксируют детали, которые бизнес должен отвечать на вопросы о том, как хорошо это делается.

Можно утверждать, что реляционная модель может также использоваться в качестве основы для ответа на деловые вопросы, но на тактическом уровне. "Сколько заказов находится в невыполненном состоянии для клиента x из-за удерживания кредита?" Но различие заключается в том, где вопрос отчетности требует "родного зерна" таблицы, и когда на отчетный вопрос можно ответить с суммированными данными.

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

Ответ 4

Я нашел описание, которое я нашел на http://www.orafaq.com/node/2286, чтобы быть очень полезным при приближении к схеме звезд с реляционной точки зрения.

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