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

Question

Я пытаюсь узнать о 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 

Это правильно?

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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

Для получения более подробной информации ознакомьтесь с подробными книгами по этой теме.

Answer 3

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

По словам Стива Hoberman в своей книге «Моделирование данных Made Simple» различие между 2 типами моделей заключается в следующем:

• Модели Relational Data захватывает бизнес-решение для того, как часть бизнес работает иначе, бизнес-процесс
• одномерные модели данных захвата деталей бизнес должен ответить на вопросы о том, насколько хорошо он делает

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

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

Answer 4

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

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