Как смоделировать таблицу измерений, которая ссылается на несколько фактов с разным уровнем зерна?

Question

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

Итак, я создал одно измерение Location со всеми штатами, всеми округами, всеми улицами. Таблица выглядит следующим образом:

DIM_ID  | Level     | Street columns        | County columns        | State columns
1       | Street    | Bolsa                 | Westminton            | California
2       | County    | Westminton [county]   | Westminton            | California
3       | State     | [State of] California | [State of] California | California

Если клиент раскрывает улицу, то ссылка на запись факта на строку 1, клиент раскрывает уровень округа, затем ссылка на запись факта на строку 2, клиент раскрывает только состояние, а затем ссылка на запись факта на строку 3.

Что вы думаете об этом подходе?

Answer 1

Я бы, вероятно, смоделировал эти уровни отдельно, поскольку они рассматриваются как отдельные, то есть:

• dim.Street
• dim.County
• dim. State

Что касается связи с клиентами, я бы пошел для таблиц моста, например:

CREATE TABLE ClientStreet
(
    ClientID
    , StreetID
)

И т.д.

И если вы не можете предоставитьУлица без предоставления округа и штата, или предоставление округа без предоставления штата, я бы имел в пределах dim.Street, CountyID и в пределах dim.County, StateID, то есть иерархической структуры.

РЕДАКТИРОВАТЬ

Что касается измерений вашего клиента с 3 идентификаторами, это также может быть хорошей моделью.

Что касается моей иерархической структуры и моделирования данных в целом, я чувствую, какВы моделируете, что это действительно нужно:

1. Отражать реальность (например, запись улицы клиента, поскольку "[Штат] Калифорния" кажется мне неточной).
2. Отражать реальность того, чтовозможно с точки зрения входящих данных, т.е. ваши клиенты вводят своиодеться один раз, или они могут изменить его (вы хотите отслеживать изменения?)?

Мне интересно одно: нужно ли вашим клиентам выбирать один или только один из этих уровней для записи? их адрес в. В этом случае у меня будет либо модель, которую я предложил выше, либо клиентское измерение с 3 идентификаторами и CHECK CONSTRAINT, чтобы обеспечить заполнение только одного из них. Тогда это будет поддерживаться тем фактом, что у улицы будет идентификатор CountyID и т. Д. Таким образом, вы можете определить этот тип «канала», по которому идентификатор заполняется в измерении клиента.