Пространственное моделирование

В этой статье указаны источники, но диапазоны ссылок на страницы слишком широкие или неверные . Пожалуйста, помогите добавить более точный диапазон страниц. ( Июнь 2018 г. ) ( Узнайте, как и когда удалять это сообщение )

Многомерное моделирование ( DM ) является частью методологии жизненного цикла бизнес-измерений, разработанной Ральфом Кимбаллом , которая включает в себя набор методов, приемов и концепций для использования при проектировании хранилища данных . ^{[1] : 1258–1260  [2]} Подход фокусируется на определении ключевых бизнес-процессов в рамках бизнеса, а также на их моделировании и внедрении в первую очередь перед добавлением дополнительных бизнес-процессов, как подход «снизу вверх» . ^{[1] : 1258–1260} Альтернативный подход от Инмона выступает за проектирование модели всех корпоративных данных сверху вниз с использованием таких инструментов, как моделирование сущности-связи (ER). ^{[1] : 1258–1260}

Размерное моделирование всегда использует концепции фактов (мер) и измерений (контекста). Факты обычно (но не всегда) представляют собой числовые значения, которые можно агрегировать, а измерения представляют собой группы иерархий и дескрипторов, которые определяют факты. Например, объем продаж является фактом; временная метка, продукт, номер регистра, номер магазина и т. д. являются элементами измерений. Размерные модели строятся по областям бизнес-процессов, например, продажи в магазине, инвентарь, претензии и т. д. Поскольку различные области бизнес-процессов разделяют некоторые, но не все измерения, эффективность в проектировании, эксплуатации и согласованности достигается с помощью согласованных измерений , т. е. с использованием одной копии общего измерения для всех предметных областей. ^{[ необходима ссылка ]}

Многомерное моделирование не обязательно подразумевает реляционную базу данных. Тот же подход к моделированию на логическом уровне может быть использован для любой физической формы, например, многомерной базы данных или даже плоских файлов. Он ориентирован на понятность и производительность. ^{[ необходима цитата ]}

Размерная модель строится на основе звездообразной схемы или схемы «снежинка» с размерами, окружающими таблицу фактов. ^{[3] [4]} Для построения схемы используется следующая модель проектирования:

1. Выберите бизнес-процесс
2. Объявляем зерно
3. Определите размеры
4. Определите факт

Выберите бизнес-процесс

Процесс размерного моделирования строится на 4-шаговом методе проектирования, который помогает обеспечить удобство использования размерной модели и использования хранилища данных . Основы проектирования строятся на фактическом бизнес-процессе, который должно охватывать хранилище данных . Поэтому первым шагом в модели является описание бизнес-процесса, на котором строится модель. Это может быть, например, ситуация продаж в розничном магазине. Чтобы описать бизнес-процесс, можно сделать это в виде обычного текста или использовать базовую модель и нотацию бизнес-процесса (BPMN) или другие руководства по проектированию, такие как Unified Modeling Language |UML).

Объявляем зерно

После описания бизнес-процесса следующим шагом в проектировании является объявление зернистости модели. Зернистость модели — это точное описание того, на чем должна фокусироваться размерная модель. Это может быть, например, «Отдельная позиция на квитанции покупателя из розничного магазина». Чтобы прояснить, что означает зернистость, вам следует выбрать центральный процесс и описать его одним предложением. Более того, зернистость (предложение) — это то, из чего вы собираетесь строить свои измерения и таблицу фактов. Возможно, вам понадобится вернуться к этому шагу, чтобы изменить зернистость из-за новой информации, полученной о том, что ваша модель должна предоставлять.

Определите размеры

Третий шаг в процессе проектирования — определение измерений модели. Измерения должны быть определены в пределах зерна из второго шага 4-шагового процесса. Измерения являются основой таблицы фактов и местом сбора данных для таблицы фактов. Обычно измерения — это существительные, такие как дата, магазин, инвентарь и т. д. Эти измерения — место, где хранятся все данные. Например, измерение даты может содержать такие данные, как год, месяц и день недели.

Определите факты

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

Нейтральность этого раздела оспаривается . Соответствующее обсуждение можно найти на странице обсуждения . Пожалуйста, не удаляйте это сообщение, пока не будут выполнены условия для этого . ( Июнь 2018 г. ) ( Узнайте, как и когда удалить это сообщение )

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

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

Разработчики часто не нормализуют размеры по нескольким причинам: ^[5]

1. Нормализация усложняет структуру данных
2. Производительность может быть ниже из-за большого количества соединений между таблицами.
3. Экономия места минимальна.
4. Индексы Bitmap использовать нельзя
5. Производительность запросов. Базы данных 3NF страдают от проблем с производительностью при агрегировании или извлечении многих размерных значений, которые могут потребовать анализа. Если вы собираетесь делать только операционные отчеты, то вы можете обойтись 3NF, поскольку ваш операционный пользователь будет искать очень мелкие данные.

Есть некоторые аргументы о том, почему нормализация может быть полезной. ^[4] Это может быть преимуществом, когда часть иерархии является общей для более чем одного измерения. Например, географическое измерение может быть повторно используемым, поскольку его используют и измерения клиента, и измерения поставщика.

This section may rely excessively on sources too closely associated with the subject, potentially preventing the article from being verifiable and neutral. Please help improve it by replacing them with more appropriate citations to reliable, independent sources. (June 2018) (Learn how and when to remove this message)

Преимущества размерной модели следующие: ^[6]

• Понятность. По сравнению с нормализованной моделью, размерная модель более понятна и интуитивно понятна. В размерных моделях информация группируется в связные бизнес-категории или измерения, что упрощает ее чтение и интерпретацию. Простота также позволяет программному обеспечению эффективно перемещаться по базам данных. В нормализованных моделях данные делятся на множество дискретных сущностей, и даже простой бизнес-процесс может привести к десяткам таблиц, объединенных сложным образом.
• Производительность запросов. Многомерные модели более денормализованы и оптимизированы для запросов данных, в то время как нормализованные модели стремятся устранить избыточность данных и оптимизированы для загрузки и обновления транзакций. Предсказуемая структура многомерной модели позволяет базе данных делать сильные предположения о данных, которые могут оказать положительное влияние на производительность. Каждое измерение является эквивалентной точкой входа в таблицу фактов, и эта симметричная структура позволяет эффективно обрабатывать сложные запросы. Оптимизация запросов для баз данных, объединенных звездой, проста, предсказуема и контролируема.
• Расширяемость. Многомерные модели масштабируемы и легко вмещают неожиданные новые данные. Существующие таблицы можно изменять на месте, просто добавляя новые строки данных в таблицу или выполняя команды SQL alter table. Никакие запросы или приложения, которые находятся поверх хранилища данных, не нужно перепрограммировать для вмещения изменений. Старые запросы и приложения продолжают работать, не давая других результатов. Но в нормализованных моделях каждое изменение следует тщательно рассматривать из-за сложных зависимостей между таблицами базы данных.

The neutrality of this section is disputed. Relevant discussion may be found on the talk page. Please do not remove this message until conditions to do so are met. (June 2018) (Learn how and when to remove this message)

Мы по-прежнему получаем преимущества размерных моделей на Hadoop и подобных фреймворках больших данных . Однако некоторые функции Hadoop требуют от нас немного адаптировать стандартный подход к размерному моделированию. ^{[ необходима цитата ]}

• Файловая система Hadoop неизменяема . Мы можем только добавлять , но не обновлять данные. В результате мы можем только добавлять записи в таблицы измерений. Медленно изменяющиеся измерения в Hadoop становятся поведением по умолчанию. Чтобы получить последнюю и самую актуальную запись в таблице измерений, у нас есть три варианта. Во-первых, мы можем создать представление , которое извлекает последнюю запись с помощью функций окон . Во-вторых, мы можем запустить службу уплотнения в фоновом режиме, которая воссоздает последнее состояние. В-третьих, мы можем хранить наши таблицы измерений в изменяемом хранилище, например, HBase, и объединять запросы по двум типам хранилищ.
• Способ распределения данных в HDFS делает соединение данных дорогим. В распределенной реляционной базе данных ( MPP ) мы можем размещать записи с одинаковыми первичными и внешними ключами на одном узле в кластере. Это делает относительно дешевым соединение очень больших таблиц. Для выполнения соединения не требуется передавать данные по сети. Это сильно отличается в Hadoop и HDFS. В HDFS таблицы разбиваются на большие фрагменты и распределяются по узлам в нашем кластере. У нас нет никакого контроля над тем, как отдельные записи и их ключи распределяются по кластеру. В результате соединения в Hadoop для двух очень больших таблиц довольно дороги, поскольку данные должны передаваться по сети. Мы должны избегать соединений, где это возможно. Для большой таблицы фактов и измерений мы можем денормализовать таблицу измерений непосредственно в таблице фактов. Для двух очень больших таблиц транзакций мы можем вложить записи дочерней таблицы в родительскую таблицу и выровнять данные во время выполнения.

• Кимбалл, Ральф ; Марджи Росс (2013). Набор инструментов для хранилищ данных: Полное руководство по многомерному моделированию (3-е изд.). Wiley. ISBN 978-1-118-53080-1.
• Ральф Кимбалл (1997). «Манифест размерного моделирования». СУБД и интернет-системы . 10 (9).
• Марджи Росс (Kimball Group) (2005). «Идентификация бизнес-процессов». Kimball Group, Design Tips (69). Архивировано из оригинала 12 июня 2013 г.