Внешнее измерение времени в кубах MySQL OLAP?

Question

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

Мой вопрос: почему?

Я просто не вижу преимущества в том, чтобы иметь time_dimension таблицу (int, timestamp), которая соединена с кубом по некоторому внешнему ключу time_id, вместо того, чтобы иметь timestamp столбец в кубе сам по себе.

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

Кроме того, тип столбца timestamp имеет ширину 4 байта (в MySQL), так же как и тип int, который в противном случае обычно был бы ключом, поэтому также нельзя экономить место.

При обсуждении этого с моими коллегами единственным разумным аргументом, который мне удалось выдвинуть, является соответствие другим измерениям. Но я нахожу этот аргумент довольно слабым.

Answer 1

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

Учитывая, что большинство кубов OLAP написаны для получения запросов с течением времени, для меня это имеет смысл.

Answer 2

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