Реляционный по сравнению с Размерными Базами данных, каково различие?
Я пытаюсь узнать о OLAP и организации хранилищ данных, и я смущен различием между реляционным и размерным моделированием. Размерное моделирующее в основном реляционное моделирование, но обеспечение redundant/un-normalized данные?
Например, скажем, у меня есть исторические данные о сбыте на (продукт, город, # продажи). Я понимаю, что следующее было бы реляционной точкой зрения:
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
Это корректно?
2 ответа
Звездная схема действительно находится на пересечении реляционной модели данных и размерной модели данных. Это действительно способ начать с размерной модели и сопоставить ее с таблицами SQL, которые чем-то напоминают таблицы SQL, которые вы получаете, если начинаете с реляционной модели.
Я говорю «отчасти похожи», потому что многие методологии реляционного дизайна приводят к нормализованному дизайну или, по крайней мере, почти нормализованному дизайну. В звездообразной схеме будут существенные отклонения от полной нормализации.
Каждое отклонение от полной нормализации влечет за собой последующую аномалию обновления данных. (Я включаю аномалии при операциях вставки, обновления и удаления под одним зонтом). Эти аномалии не имеют ничего общего с той моделью данных, с которой вы начали.
Здесь уместен комментарий о сравнении OLTP и OLAP.Аномалии обновления будут по-разному влиять на производительность и / или сложность программирования в этих двух ситуациях.
В дополнение к схеме «звезда» в базе данных SQL существуют продукты для многомерных баз данных, которые хранят данные в физической форме, уникальной для этого продукта. С этими продуктами вы не столько видите звездную схему, сколько видите прямую реализацию размерной модели и интерфейс, который может быть специфическим для продукта. Некоторые из этих интерфейсов позволяют выполнять операции OLAP одним щелчком мыши.
В качестве отступления от вашего вопроса я однажды построил звездную схему в качестве промежуточного шага между базой данных OLTP, которая поддерживает приложение на основе транзакций, и кубом данных внутри Cognos PowerPlay. Используя стандартные методы ETL, комбинированный перенос из базы данных OLTP в звездообразную схему, а затем из звездообразной схемы в куб данных фактически превзошел прямую передачу из базы данных OLTP в куб данных. Это был неожиданный результат.
Надеюсь, это поможет.
Проще говоря, нормализованные базы данных OLTP спроектированы с наиболее оптимальной «транзакционной» точки зрения. Базы данных нормализованы для оптимальной работы в транзакционной системе. Когда я говорю об оптимизации транзакционной системы, я имею в виду ... переход к состоянию проектирования структуры базы данных, где все транзакционные операции, такие как удаление, вставка, обновление и выбор, сбалансированы, чтобы придать им одинаковую или оптимальную важность в любой момент времени .. . поскольку они одинаково ценятся в транзакционной системе.
И это то, что предлагает нормализованная система ... минимальные обновления, возможные для обновления данных, минимальная возможная вставка для новой записи, одно место для удаления для удаления категории и т. Д. (Например, новая категория продукта) ... все это возможно в нашем филиале создание основных таблиц ... но это происходит за счет задержки операции "select" ... но, как я уже сказал, это (нормализация) не самая эффективная модель для всех операций ... ее "оптимальная" ... получить другие методы для повышения скорости выборки данных ... например, индексирование и т. д.
С другой стороны, размерная модель (в основном используется для проектирования хранилищ данных) ... предназначена для придания важности только одному виду операций, а именно Выбор данных .. .as в хранилищах данных .. обновление / добавление данных происходит периодически .. и это единовременная стоимость.
Итак, если кто-то попытается настроить нормализованную структуру данных так, чтобы только выбор был наиболее важной операцией в любой момент времени ... мы в конечном итоге получим денормализованную (я бы сказал, частично денормализованную) .. размерную звездную структуру.
- все внешние ключи в одном месте Факт
-нет измерения к объединению измерений (т. е. соединение главной таблицы с главной).снежинка представляет такое же измерение
- идеально спроектированные факты несут только числа .. измерения или внешние ключи
- измерения используются для переноса описания и неагрегируемой информации
- избыточность данных игнорируется ... но в редких случаях, если сами измерения слишком сильно растут. Дизайн в виде снежинки рассматривается как вариант… но этого все же можно избежать
Для получения подробной информации, пожалуйста, просмотрите подробные книги по этой теме.