ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / Дизайн измерения
6 сообщений из 6, страница 1 из 1
Дизайн измерения
    #32942379
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AAron
Участник
Всем привет.
Есть измерение Лимиты, "Limits_Dim" (пусть, SCD 2):
unique_id int not null - уникальный идентификатор, генерируется при добавлении новой записи.

limit_id into not null - идентификатор лимита.
Каждый Лимит обладает набором атрибутов:

Name - название

Type - тип

К каждому лимиту может быть привязано несколько рынков - Markets. Иными словами, между Limits_Dim и Markets отношение N к M. В реляционке можно разложить через третью таблицу.

Непонятно, как сделать аналогичную вещь в dimension modeling? Если делать также через третью таблицу, то насколько это удобно/неудобно?

PS. Собственно, приведенные сущности - это пример. Общей является задача отражение связей N к М.
...
Рейтинг: 0 / 0
02.03.2005, 20:18
| Ответить | Цитировать | Написать  
Дизайн измерения
    #32942495
Владимир Штепа
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир Штепа
Участник
Уважаемый ААрон, в традициях форума указывать инструмент, к которому относится ваш вопрос.

Опережая ваше уточнение скажу, что в AS2K N2M одно из возможных решений это дополнительный кубов, который обхединяется с основным кубом в виртуальном кубе.

В AS2K5 этот функционал out-of-box.
...
Рейтинг: 0 / 0
02.03.2005, 22:43
| Ответить | Цитировать | Написать  
Дизайн измерения
    #32942562
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AAron
Участник
уважаемый, backfire, я учту. но я задал немного другой вопрос, и он не касается какого либо инструмента, как такогого.

Задам его по другому.
Итак
Есть измерение [Лимиты]
Возьмем отдельный Лимит1. У него есть некие атрибуты одного класса Рынок: Рынок1_1, Рынок2_1, ..., РынокN_1. У Лимита2 набор атрибутов другой: Рынок1_2, Рынок2_2, ..., РынокМ_2. И так далее.
Скрипт для создания этих отношений в реляционной структуре обычной OLTP-базы данных:
Код: plaintext
1.
2.
3.
create table Limits (limit_id int not null, description char( 200 ))
create table Markets (market_id int not null, name char( 20 ))
create table LimitsMarket(limit_id int not null, market_id int not null)
Ну и разумеется констрейнты между таблицами.
Теперь перейдем к DWH. Исходим, что таблица Markets статична, она не будет являться измерением, названия не будут изменяться, удаляться и т.п. В таком случае, скрипт создания для измерения Limits_Dim (SCD2):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
create table Limits_Dim (
unique_id int not null, /*Суррогатный ключ, генерируется при добавлении информации об изменении*/
limit_id int not null, /*Идентификатор лимита*/
start_date datetime not null, /*Дата начала действия версии*/
end_date datetime not null, /*Дата окончания действия версии*/
is_active_state bit not null /*Признак активного состояния. Устанавливается в 1 для активного состоянию,
служит для упрощения поиска*/
)
Разумеется в этом измерении я не могу перечислять все указанные выше рынки. Я думаю, что можно сделать дополнительную таблицу такого вида:
Код: plaintext
1.
2.
3.
4.
create table Limits_dim_market_add (
unique_id int not null, /*идентификатор суррогатного ключа*/
limit_id int not null, /*идентификатор лимита*/,
Market_Name not null /*название Рынка из таблицы Рынков*/
)
Таким образом, SQL-запрос, по получению списка лимитов, установленных в настоящий момент, скажем на Рынок1, будет такого вида:
Код: plaintext
1.
2.
3.
4.
select L.*
from Limits_Dim L
inner join Limits_dim_market_add MA on MA.unique_id = L.unique_id
where L.is_active_state =  1  and MA.Market_Name = 'Рынок1'

Собственно вопрос . Насколько корректен (или некорректен) предложенный подход? Случалась ли в Вам моделировать такую ситуацию?

PS. Вообще, это вопрос по проектированию измерения в DWH, а не конкретное использование в OLAP.
...
Рейтинг: 0 / 0
03.03.2005, 00:42
| Ответить | Цитировать | Написать  
Дизайн измерения
    #32942584
Владимир Штепа
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир Штепа
Участник
пока все понятно и "криминала" в вашем решении на первый взгляд не видно. по крайней мере все логично.

Идем дальше.
Измерение то измерением, но как вы его к таблице фактов привязывать собираетесь?
Сами то по себе измерения мало кого интересут - это просто контекст в котором рассматриваются фактические данные.
...
Рейтинг: 0 / 0
03.03.2005, 01:48
| Ответить | Цитировать | Написать  
Дизайн измерения
    #32942978
Dmitry Biryukov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dmitry Biryukov
Участник
AAronСобственно, приведенные сущности - это пример. Общей является задача отражение связей N к М.
Сущности и связи - это из области баз данных.
В OLAPе оперируют другими терминами.
В зависимости от решаемых задач, я бы предложил несколько подходов:
1. два отдельных плоских измерения Лимиты и Рынки. В таблице фактов указываются и рынок и лимит.
2. Создаётся одно измерение с двумя уровнями Лимиты и Рынки (можно дополнительно создать и несколько виртуальных), в таблице фактов указывается ИД пары (лимит-рынок) - Limits_dim_market_add.unique_id

по поводу scd - почитайте прошлые посты.
http://www.sql.ru/forum/actualtopics.aspx?search=scd&bid=26
...
Рейтинг: 0 / 0
03.03.2005, 10:36
| Ответить | Цитировать | Написать  
Дизайн измерения
    #32943568
OLAPMASTER
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OLAPMASTER
Участник
Есть измерение [Лимиты]
Возьмем отдельный Лимит1. У него есть некие атрибуты одного класса Рынок: Рынок1_1, Рынок2_1, ..., РынокN_1. У Лимита2 набор атрибутов другой: Рынок1_2, Рынок2_2, ..., РынокМ_2. И так далее.

Исходя из этого я понимаю что 1 лимит на несколько рынком и решаеш зарачу 1 к N??
причем сдесь вообще N к M (это многий ко многим так обозначешь что ли)

Так непонятно что то, ты одной таблицей обойдешся спокойно.
create table ALL(
limit_id PK
Market_Name PK
start_date
end_date
is_active_state )

диалек MS SQL Server я убрал.

Ну и что мы вилим составной Первичный ключ (правдо я никогда их не использую) и все видно.
Остаеться вопрос что лежит в таблице фактов???
...
Рейтинг: 0 / 0
03.03.2005, 13:31
| Ответить | Цитировать | Написать  
6 сообщений из 6, страница 1 из 1
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / Дизайн измерения
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]