Реляционные и многомерные базы данных, какая разница?
Я пытаюсь узнать об OLAP и хранилищах данных, и я смущен разницей между реляционным и размерным моделированием. Является ли размерное моделирование в основном реляционным моделированием, но допускающим избыточные/ненормализованные данные?
например, предположим, у меня есть исторические данные о продажах (продукт, город, # sales). Я понимаю, что следующим будет реляционная точка зрения:
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
это правильно?
4 ответов
схеме "звезда" действительно лежит на пересечении реляционной модели данных и пространственные модели данных. Это действительно способ начать с размерной модели и сопоставить ее с таблицами SQL, которые несколько напоминают таблицы SQL, которые вы получаете, Если вы начинаете с реляционной модели.
Я говорю несколько похож, потому что многие методологии реляционного дизайна приводят к нормализованному дизайну или, по крайней мере, почти нормализованному дизайну. Звездная схема будет иметь значительные отклонения от полной нормализации.
каждый отход от полной нормализации несет с собой последующую аномалию обновления данных. (Я в том числе anomlaies на вставку, обновление и удаление операций под одним зонтом). Эти аномалии не имеют ничего общего с той моделью данных, с которой вы начали.
комментарий по OLTP против OLAP актуален здесь. Аномалии обновления будут иметь различные последствия для производительности и / или сложности программирования в этих двух положения.
в дополнение к схеме звезды в базе данных SQL существуют продукты размерных баз данных, которые хранят данные в физической форме, уникальной для этого продукта. С этими продуктами вы не видите звездную схему, а видите прямую реализацию размерной модели и интерфейс, который может быть характерен для продукта. Некоторые из этих интерфейсов позволяют операциям OLAP быть полностью point-and-click.
просто как отступление от ваш вопрос: однажды я построил схему star в качестве промежуточного шага между базой данных OLTP, поддерживающей приложение на основе транзакций, и кубом данных внутри Cognos PowerPlay. Используя стандартные методы ETL, комбинированная передача из базы данных OLTP в схему star, а затем из схемы star в куб данных фактически превзошла прямую передачу из базы данных OLTP в куб данных. Это был неожиданный результат.
надеюсь, что это помогает.
простыми словами OLTP нормализованные базы данных разработаны с наиболее оптимальной "транзакционной" точки зрения. Базы данных нормализуются для оптимальной работы с транзакционной системой. Когда я говорю "оптимизация транзакционной системы", я имею в виду ..переход к состоянию проектирования структуры базы данных, где все транзакционные операции,такие как delete,insert, update и select, сбалансированы, чтобы придать одинаковую или оптимальную важность всем из них в любой момент времени...поскольку они одинаково ценятся в транзакционной система.
и это то, что предлагает нормализованная система ..минимальные обновления для обновления данных, минимальная вставка для новой записи, удаление одного места для удаления категории и т. д. (Например, новая категория продукта )...все это возможно, мы ветвь a создать мастер-таблицы .....но это происходит за счет задержки операции" select"..но, как я уже сказал, его(нормализация) не самая эффективная модель для всех операций ..его "оптимальный"...сказав, что мы получаем другие методы для улучшения выборки данных скорость..как индексирование и т. д.
с другой стороны, размерная модель (в основном используется для дизайна дома данных)..предназначен для придания значения только одному виду операций, что выбор данных...как в хранилищах данных ..обновление/вставка данных происходит периодически ..и это одноразовая стоимость.
поэтому, если попытаться настроить нормализованную структуру данных так, чтобы только выбор был самой важной операцией в любой момент времени ...мы в конечном итоге получим денормализованный (я бы сказал частично ненормированные)..размерная звездная структура.
- все внешние ключи одно место факт
- нет измерения для соединения измерений (т. е. мастер для мастер-таблицы)..снежинка представляет то же измерение
- идеально разработанные факты несут только цифры ..меры или внешние ключи
- dimension используются для переноса описания и не агрегируемой информации
- избыточность данных игнорируется ...но в редких случаях, если размеры сами растут слишком много .снежинка дизайн рассматривается как вариант..но этого еще можно избежать!--12-->
для получения подробной информации, пожалуйста, просмотрите подробные книги по этой теме.
недавно я прочитал о разнице между размерным и реляционным моделированием данных, поскольку мы в основном используем реляционные модели в моем бизнесе, где мы храним корпоративное хранилище данных (EDW).
по словам Стива Хоберман в своей книге "моделирование данных простое" различие между 2 типами моделей это:
- модели реляционных данных отражает бизнес-решение как часть бизнеса работает.к.бизнес процесс
- модели размерных данных захватить детали бизнес должен ответить на вопросы о том, насколько хорошо он делает
можно утверждать, что реляционная модель также может использоваться в качестве основы для ответа на деловые вопросы, но на тактическом уровне. "Сколько заказов находится в невыполненном состоянии для клиента x из-за удержания кредита?"Но различие заключается в том, где вопрос отчетности нуждается в "родном зерне" таблицы и когда на вопрос об отчетности можно ответить обобщенными данными.
в приведенных выше 2 примерах они фактически являются примерами моделирования размерных данных, поскольку ни одна из 2 таблиц не хранит заказ на продажу в своем "собственном зерне" и, следовательно, не захватывает бизнес-процесс создания заказа на продажу. Единственное различие между 2 таблицами заключается в том, что во 2-й таблице измерение города было перенесено в таблицу фактов.
Я нашел описание, которое я нашел на http://www.orafaq.com/node/2286 быть очень полезным при переходе к схеме звезды с реляционной точки зрения.
рассмотрим полностью нормализованную модель данных. Теперь думаю, ровно наоборот, где вы полностью денормализация реляционной модели данных так, что у вас только одна квартира записывать большой файл в стандартном телефоне с очень широкой строке. Теперь отступите от этой плоской записи немного, чтобы у вас была модель данных это только два уровня в глубину; один большой стол и несколько маленьких столов, на которые указывает большой стол. Это схемы типа "звезда". Таким образом, модель данных true star имеет два атрибута, она всегда имеет два уровня глубины, а модель true star всегда содержит только одну большую таблицу, которая является фокусом модели.