Блог

Создание таблицы измерений местоположения для DW; Я знаком с датой / временем, но для определения местоположения я использую эти столбцы: Континент, страна, регион, город, Почтовый. Теперь вопрос в том, что, если запись не имеет города или почтового отправления и заканчивается только регионом. В DW все записи будут содержать город, но в таблице фактов могут быть данные, в которых их не будет, поскольку это необязательные точки данных при сборе опроса, так как приступить к разработке этой таблицы? Нужно ли мне сначала вставлять строки только для страны, только города, только почты и т.д., Оставляя остальные поля пустыми, А затем выстраивать отношения, такие как континент к стране и т.д.?

Два основных способа справиться с этим.

1. Используйте unknown для пропущенных значений. Таким образом, у каждого города есть неизвестный почтовый индекс, у каждого региона есть неизвестный город. Таким образом, местоположение, которое заканчивается на region , имеет City='unknown' , Postal='unknown'

2. Просто используйте только столбцы, которые существуют во всех записях — в этом случае удалите city и postal столбцы.

За свою жизнь я создал несколько измерений местоположения, и в настоящее время я управляю системой с большим измерением местоположения. Я описал, как я это сделал, в своем блоге. https://dimensionalmodelingblog.wordpress.com/creating-a-location-dimension-in-a-data-warehouse /

Измерение местоположения — сложная задача, и даже Ральф Кимбалл признает, что это непростая задача (см. главу 10 о создании хранилища данных).

В вашем случае вам действительно нужно 5 измерений, по одному для каждого уровня и его уровней выше (одно измерение для континента, страны, региона, города, почты, одно для континента, страны, региона, города и т.д.) Когда у вас есть данные, в которых нет информации о городе, вы используете измерение региона и т.д.

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

Ваша таблица будет выглядеть следующим образом Континент, страна, регион, город, почтовый индекс, уровень 1, уровень 2, уровень 3, уровень 4, уровень 5

Ваш процесс помечает все записи нужного уровня соответствующим значением, а первую запись каждого уровня — значением следующего уровня: Например, у вас есть 15 городов в американском регионе Колорадо, каждый из них имеет флаговый уровень 4, а первый — флаговый уровень 3. Затем в представлении locationCity отображаются первые 4 столбца и фильтры с флагом level4, а в представлении LocationRegion отображаются первые 3 столбца и фильтры с флагом level3.

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

решение @Darmir интересное, его большим плюсом является то, что оно хранит географические данные в одной таблице, недостатком является то, что вы получаете очень большое количество записей с «неизвестными» для континентов, стран, регионов, городов, почтовых комбинаций — либо генерируемых на лету во время ETL, либо в качестве одноразовой загрузки (если это можно сделать окончательно).

Очевидно, что здесь существует естественная иерархия, поэтому мы хотели бы попробовать ее использовать.

Но в качестве альтернативы, я думаю, было бы интересно создать несколько таблиц измерений вместо одной. В худшем случае у вас может быть своя таблица фактов с суррогатными ключами для каждого из DimContinent, DimCountry, Dimregion, DimCity и DimPostCode. Но при некотором профилировании может оказаться возможным удобно сгруппировать эти таблицы вместе. Рассмотрим следующие вопросы…

1. существуют ли какие-либо поля, которые (всегда / обычно) заполняются?
2. существуют ли наборы полей, которые, если заполнить одно, будут заполнены и остальные?
3. можете ли вы получить некоторые окончательные справочные данные, чтобы улучшить и заполнить недостающие данные?

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

Вы говорите «В DW все записи будут содержать город», поэтому, если бы вы могли найти способ обогатить свои данные (шаг 3), тогда вы могли бы создать таблицу с размерами городов, содержащую (Континент / Страна / Регион / Город).

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

Я не совсем уверен в себе в этом решении, но подумал, что я бы предложил его на случай, если это поможет.