Уровень публикации и витрины

1.

Уровень
Публикаци
и
и
Витрины
данных

2.

Архитектурные принципы построения «Ядра»
Р
Извлечение, Выделение дельты, Маппинг приложений, Унификация
записей, Преобразование ключей, Унификация артрибутов, История
Data Warehouse
Source
Integration
Staging
DWH
Ядро DWH
ODS
Приложения КБ:
(LoanManager,
AlfaFactoring, AlfaLeasing,
DBO, ..)
Приложения РБ:
(GEMINI, SLOLP RB,
SLOLP CF, SLOLP AK,
SLOLP MG, WSRM, CCM,
DebtManager, ПО Legal,
PDS, Credit Dossier,
Smart Vista, ..)
Виртуальное Ядро DWH
(Представления детальных
данных)
Приложения
Казначейства (БД
Фондирование,
администратор ставок)
Интерфейсный уровень Staging
Приложения
коммерческого Блока
(Credit, SalesLogix, СКС,
Вексельный Центр, ...)
Область выгрузки
Приложения
инвестиционного Блока
(FOCUS,OPICS,SMART, )
Интерфейсный уровень
Система интерфейсов
ручного ввода
Перенос
Данные ДАБов
ПО Холдинга
Staging «Ядра DWH»
АБС EQUATION
Ядро DWH
(Хранимые детальные данные РСБУ)
Системыисточники
А1. Отражение
З
О
В
А
Н
И данных
Я
состояния
Отчет-специфические
наBI-специфические
Источниках
в согласованном,
преобразования
преобразования
интегрированном виде
Business Intelligence
BI Front Ends
DataMarts
(Аналитические
2. Служит Источником данных
Oracle BI
для всех зависимых
Data Mart
Бизнеспользоват ели
Внешние
системы
системы)
«Бизнес-ETL», «Бизнесметаданные»
Система
Коррекций
DM ФБ
Отчетность
ФБ
3. Обеспечивает «time variant»:
хранение истории изменений
Отчетность
для
КБ
всех изменяющихся размерностей
DM КБ
и фактов
DM Экспорт
в KRM
KRM
DM ФО
Б
(Детальные данные МСФО)
О
CRM
BMB
Staging
DM КБ
Staging
DM Казн.
DM
Казн-во
Отчетность
Казначейства
Loan
Manager
4. Хранит Только детальные данные
и Только в РСБУ. BI-Кредитный
портфель
специфические обогащения и
Отчетность
агрегаты рассчитываются
и
Collection
хранятся в соответствующих Data
Mart-ах
Staging
DM RWA
DM
ФВ RWA
MGR
DM РБ
Е
Staging DM ФО
Р
Слой
синхронизации
Staging DM РБ
П
Staging
DM ACRM
DM
ACRM
Staging
DM Coll-n
DM
Collection
Staging
DM УРР
DM
УРР
Staging
DM PL
DM PL
Системы
потребители
Отчетность для
ОперБлока
Отчетность для
прочих Блоков
Системы
потребители
5. Загружается
Staging инкрементально
на основе
DM PR
DM PR
Delta detection
Потоки обмена данными изменений
Отчетность Витрины
процессов
Системы
потребители
DM BUS
6. Обеспечивает хранение
Метаданные BIдетальных
данных
Централизованный Репозитарий
Метаданных необходимой длительности
Job Management, Метаданные Informatica

3.

Типы таблиц презентационного слоя
Тип
Постфикс
Назначение
Размерность
LOV
Списки значений
Размерность
LDIM
Размерности без ссылок на другие размерности
Размерность
SDIM
Размерности со ссылками на другие размерности
Размерность
HDIM
Размерности с поддержкой технической истории
Размерность
EDIM
Размерности с поддержкой бизнес-периодов действия
Размерность
VDIM
Размерности с поддержкой версий данных
Размерность
XDIM
Неизменяемые свободнопополняемые размерности
Факт
TRAN
Статические транзакционные факты (DELETE-INSERT)
Факт
STRAN
Транзакционные факты без поддержки технической истории
Факт
HTRAN
Транзакционные факты с поддержкой технической истории
Факт
STAT
Статические состояния (DELETE-INSERT)
Факт
SSTAT
Состояния без поддержки технической истории
Факт
LSTAT
Текущие состояния (LAST)
Факт
HSTAT
Состояния с поддержкой технической истории
Факт
VHIST
Факт
SHIST
Группа
GROUP
Факты с заданным бизнес-периодом действия с поддержкой технической
истории
Факты с заданным бизнес-периодом действия без поддержки технической
истории
Определения групп
Группа
GRDEF
Привязка экземпляров размерностей к группам
Агрегат
SAGG
Агрегаты без поддержки технической истории
Агрегат
VAGG
Агрегаты с поддержкой версий данных
Агрегат
HAGG
Агрегаты с поддержкой технической истории
Отчет
RPT
Данные отчетных форм

4.

Временные интервалы
Бизнес-период действия
EFFECTIVE_FROM <= date <
EFFECTIVE_TO
Техническая история
VALIDFROM <= date < VALIDTO
…
Ставка
…
EFFECTIVE_FROM
(с источника)
EFFECTIVE_TO
(с источника )
AS_OF_DAY
(метаданные)
VALIDFROM
(метаданные)
VALIDTO
(метаданные)
14
…
25.03.2010
01.04.2010
21.03.2010
20.03.2010
23.03.2010
25.03.2010
01.04.2010
24.03.2010
23.03.2010
31.12.5999
01.04.2010
29.04.2010
25.03.2010
24.03.2010
31.12.5999
15
16
…

5.

Служебные записи в размерностях
Данные записи используются для обеспечения
обязательного заполнения ссылочных атрибутов
в Хранилище.
UK
CCODE
NAME
…
-1
N/A
Неверное значение
…
0
N/D
Не определено
…
…
…
…
…

6.

Размерности – списки значений (*_LOV)
UK
CCODE
NAME
-1
N/A
Неверное значение
0
N/D
Не определено
1
M
Мужской
2
F
Женский

7.

Размерности без истории и без ссылок (*_LDIM)
LDIM - таблицы размерностей без истории
• Отсутствуют ссылки на другие
размерности
• Данные поступают из систем
источников
• Данные в таблицы такого типа
загружаются в первую очередь
UK
NAME
AS_OF_DAY
…
…
…
21.01.2010
…
…
…
Пример: справочник наименований страховых компаний
…
…
10
РОСНО
11
…

8.

Размерности статические (*_SDIM)
SDIM - таблицы размерностей без истории
• Присутствуют ссылки на другие
размерности
• Данные поступают из систем источников
Пример: справочник бирж
UK
Наименование
Код адреса
Алиас
AS_OF_DAY
…
…
…
…
…
…
…
10
Chicago stock
exchange
287
CHX
28.01.2010
…
11
…
…
…
…

9.

Размерности – с поддержкой истории (*_HDIM)
HDIM - таблица размерности с технической
историей
• Могут присутствовать ссылки на другие
размерности
• Данные поступают из систем - источников
• Вставка новой записи при изменении
значения атрибута, по которому ведется
UK
Имя
Город
AS_OF_DAY
VALIDFROM
VALIDTO
история
1
Иван
Тверь
23.03.2010
Пример: клиентский справочник
UK
Имя
Город
AS_OF_DAY
22.03.2009
VALIDFROM
31.12.5999
VALIDTO
1
Иван
Тверь
23.03.2010
22.03.2009
29.04.2009
1
Иван
Вологда
30.04.2009
29.04.2009
31.12.5999

10.

Размерности – неизменяемые свободнопополняемые
(*_XDIM)
XDIM - данные добавляются, но не
модифицируются
• В отличие от LOV, данные поступают из
исходных систем
UK
…
• Основное требование: ограниченное
количество комбинаций
значений в
EMPLOYEE_SDIM
ФИО
Должность
…
UK
ФИО
JOBTITLE_NK
исходных
данных
(<1000).
…
…
…
…
…
…
…
…
10
Иванов И.И.
Руководитель
…
10
Иванов И.И.
1
…
11
Петров П.П
Аналитик
…
11
Петров П.П
2
…
12
Сидоров С.С.
Аналитик
12
Сидоров С.С.
2
JOBTITLE_XDIM
NK
Должность
…
1
Руководитель
…
2
Аналитик
…

11.

Размерности с историей изменения атрибутов(*_EDIM)
EDIM – используются на витринах,
содержат бизнес-сроки действия
EFFECTIVE_FROM/TO
SDIM
UK, NAME
VHIST
ПЦ-1
ПЦ-2
Статус-1
VHIST
Статус-2
timeline
UK
NAME
UK, NAME
ПЦ
Статус
UK, NAME
EDIM 1
ПЦ-1
Основной
ПЦ-1
ПЦ-2
Статус-1
1
Статус-1
Основной
ПЦ-2
Статус-1
Статус-1
1
Основной
ПЦ-2
Статус-2
EFFECTIVE_
EFFECTIVE_
UK, NAME
FROM
TO
01.03.2010 ПЦ-2
05.03.2010
Статус-2
05.03.2010
08.03.2010
08.03.2010
12.03.2010

12.

Факты: транзакционные без поддержки истории (*_TRAN)
TRAN - транзакционные факты
• только вводятся, но не меняются (DELETEINSERT)
• транзакционный факт отражает события в
исходной системе
Пример:
учетVALUE_DAY
cach/fee ATM
транзакций
Сумма
Код валюты
Код типа
транзакции
(бизнес – дата
транзакции)
4000
28.03.2010
8000
27.03.2010
транзакции
Код издателя
карты
Номер
банкомата
Код
региона
AS_OF_DAY
810
456
341
1305
199
29.03.2010
810
456
976
54
789
29.03.2010
P
E
D
D
E
T
A
C
E
R

13.

Факты: состояния без поддержки истории (*_STAT)
STAT - факт состояния, соответствует “снимку”
состояния исходной сущности на конкретный
момент времени (например, на конец дня)
• факты состояний на каждый день
• только вводятся, но не меняются.
Пример: просрочки платежей по кредитам
Счет
VALUE_DAY
(дата остатка)
Кол-во дней
просрочки
общее
Количество дней
просрочки по
штрафам
Сумма
просрочки
общая
AS_OF_DAY
40703810400020008374
23.03.2010
12
4
6598
24.03.2010
…
…
…
P
E
D
D
E
T
A
C
E
R
…

14.

Факты: состояния с поддержкой истории (*_HSTAT)
HSTAT - факты состояний на каждый день, в
которых состояние на конкретный момент времени
Остаток
по состоянию на 22.01.2010
может
изменяться
…
Счет
Сумма
…
…
…
42301810000271837263
100
…
42301810000271837263
…
42301810000271837263
VALUE_DAY
AS_OF_DAY
VALIDFROM
VALIDTO
…
…
…
…
…
20.01.2010
21.01.2010
20.01.2010
31.12.5999
…
200
21.01.2010
22.01.2010
21.01.2010
31.12.5999
…
300
22.01.2010
23.01.2010
22.01.2010
31.12.5999
…
(дата остатка)
…
…
Остаток по состоянию на 29.01.2010
…
Счет
Сумма
VALUE_DAY
VALIDFROM
VALIDTO
…
…
…
…
…
…
…
…
42301810000271837263
100
20.01.2010
21.01.2010
20.01.2010
31.12.5999
…
…
42301810000271837263
200
21.01.2010
22.01.2010
21.01.2010
31.12.5999
…
…
42301810000271837263
300
22.01.2010
23.01.2010
22.01.2010
29.01.2010
…
…
42301810000271837263
350
22.01.2010
30.01.2010
29.01.2010
31.12.5999
…
42301810000000000011
…
…
…
…
…
42301810000271837263
850
30.01.2010
29.01.2010
31.12.5999
(дата остатка)
29.01.2010
AS_OF_DAY

15.

Факты: состояния без технической истории (*_SSTAT)
SSTAT – Используется на витринах для
хранения последнего актуального среза
данных на каждый день
(Загружаются
значения исходного HSTAT c VALIDTO =
Остаток по состоянию на 22.01.2010
31.12.5999)
…
Счет
Сумма
VALUE_DY
AS_OF_DAY
…
(дата остатка)
…
42301810000271837263
100
20.01.2010
21.01.2010
…
…
42301810000271837263
200
22.01.2010
…
…
42301810000271837263
300
21.01.2010
22.01.2010
23.01.2010
…
VALUE_DAY
AS_OF_DAY
…
Остаток по состоянию на 29.01.2010
…
Счет
Сумма
…
…
…
…
42301810000271837263
100
20.01.2010
21.01.2010
…
…
42301810000271837263
200
21.01.2010
22.01.2010
…
…
42301810000271837263
350
22.01.2010
30.01.2010
…
42301810000271837263
…
…
…
42301810000271837263
850
(дата остатка)
…
29.01.2010
30.01.2010

16.

Факты: состояния без технической истории (*_LSTAT)
LSTAT – Используется на витринах для
хранения последнего актуального среза
данных в разрезе сущности
…
Сделка
…
…
…
LOAN-1
100
22.01.2010
23.01.2010
…
…
LOAN-2
155
22.01.2010
23.01.2010
…
…
LOAN-3
123
22.01.2010
23.01.2010
…
…
Доход
VALUE_DAY
AS_OF_DAY
…
…
…
…

17.

Факты: транзакционные с поддержкой истории
(*_HTRAN)
HTRAN - транзакционные факты – могут
изменяться с течением времени

18.

Факты: транзакционные с поддержкой истории
(*_HTRAN)
Система – источник по состоянию на 31.01.2010
Пример: проводки с
поддержкой
историчности
Дебет
Кредит
Сумма
ПЦ
Дата
42301810000271837263
42301810000000000011
50
123
31.01.10
42301810000271837263
42301810000000000011
100
234
31.01.10
42301810000271837263
42301810000000000011
150
345
31.01.10
Система – источник по состоянию на 01.02.2010
Дебет
Кредит
Сумма
ПЦ
Дата
42301810000271837263
42301810000000000011
50
123
31.01.10
42301810000271837263
42301810000000000011
100
200
31.01.10
42301810000271837263
42301810000000000011
150
345
31.01.10
DWH по состоянию на 31.01.2010
Дебет
Кредит
Сумма
UK
ПЦ
VALUE_DAY
AS_OF_DAY
VALIDFROM
VALIDTO
42301810000271837263
42301810000000000011
50
11
31.01.2010
01.02.2010
31.01.2010
31. 12.5999
42301810000271837263
42301810000000000011
100
12
31.01.2010
01.02.2010
31.01.2010
31. 12.5999
42301810000271837263
42301810000000000011
150
13
31.01.2010
01.02.2010
31.01.2010
31. 12.5999
(дата проводки)
DWH по состоянию на 01.02.2010
Дебет
Кредит
Сумма
UK
ПЦ
VALUE_DAY
AS_OF_DAY
VALIDFROM
VALIDTO
42301810000271837263
42301810000000000011
50
11
31.01.2010
31.01.2010
31.01.2010
31. 12.5999
42301810000271837263
42301810000000000011
100
12
31.01.2010
31.01.2010
31.01.2010
01. 02.2010
42301810000271837263
42301810000000000011
150
13
31.01.2010
31.01.2010
31.01.2010
31. 12.5999
42301810000271837263
42301810000000000011
100
23
31.01.2010
02.02.2010
01.02.2010
31. 12.5999
(дата проводки)

19.

Факты: транзакционные без технической истории
(*_STRAN)
STRAN –
Используется на
витринах для
хранения
последнего
актуального среза
данных
Система – источник по состоянию на 31.01.2010
Дебет
Кредит
Сумма
ПЦ
Дата
42301810000271837263
42301810000000000011
50
123
31.01.10
42301810000271837263
42301810000000000011
100
234
31.01.10
42301810000271837263
42301810000000000011
150
345
31.01.10
Система – источник по состоянию на 01.02.2010
Дебет
Кредит
Сумма
ПЦ
42301810000271837263
42301810000000000011
50
123
31.01.10
42301810000271837263
42301810000000000011
100
200
31.01.10
42301810000271837263
42301810000000000011
(Загружаются
значения
DWH по состоянию на 31.01.2010
исходного
HTRAТКредит
c
Дебет
Сумма
UK
VALUE_DAY
ПЦ
VALIDTO =
42301810000271837263
42301810000000000011
50
11
31.01.2010
31.12.5999)
150
345
31.01.10
(дата проводки)
AS_OF_DAY
31.01.2010
42301810000271837263
42301810000000000011
100
12
31.01.2010
31.01.2010
42301810000271837263
42301810000000000011
150
13
31.01.2010
31.01.2010
DWH по состоянию на 01.02.2010
Дебет
Кредит
Сумма
UK
ПЦ
VALUE_DAY
AS_OF_DAY
42301810000271837263
42301810000000000011
50
11
31.01.2010
31.01.2010
42301810000271837263
42301810000000000011
100
23
31.01.2010
02.02.2010
42301810000271837263
42301810000000000011
150
13
31.01.2010
31.01.2010
(дата проводки)
Дата

20.

Факты с периодом действия на источнике или истории изменения
размерностей (*_VHIST)
VHIST - Факты с заданным на источнике периодом действия
Например: процентная ставка по кредитам, действующая в течении
заданного интервала времени
…
Ставка
…
EFFECTIVE_FROM(
с источника)
EFFECTIVE_TO(
с источника )
AS_OF_DA
Y
VALIDFROM
(метаданные)
VALIDTO
(метаданные)
14
…
25.03.2010
01.04.2010
25.03.2010
24.03.2010
31.12.5999
16
…
01.04.2010
29.04.2010
25.03.2010
24.03.2010
31.12.5999
Истории изменения размерностей
Например: история изменения адреса клиента
ID
клиента
Город
Улица
Дом
Квартира
AS_OF_DAY
VALIDFROM
VALIDTO
5690
Тверь
Речная
37
56
25.03.2010
24.03.2010
18.04.2010
5690
Москва
Павлова
34
238
19.04.2010
18.04.2010
31.12.5999

21.

Факты с периодом действия на источнике
без технической истории (*_SHIST)
SHIST – Используется на витринах для хранения
последнего актуального среза данных
(Загружаются значения исходного VHIST c VALIDTO =
31.12.5999)
Например: процентная ставка по кредитам, действующая в течении
заданного интервала времени
…
Ставка
…
EFFECTIVE_FROM
(с источника)
EFFECTIVE_TO
(с источника )
AS_OF_DAY
14
…
25.03.2010
01.04.2010
25.03.2010
16
…
01.04.2010
29.04.2010
25.03.2010

22.

Группы – (*_GROUP и *_GRDEF)
Группы – группы экземпляров какой-либо
Пример: Роли клиентов сущности.
Таблица
Поле
Описание
Домен
CLIENTROLE_GRDEF
CLIENTROLE_GRDEF
CLIENTROLE_GRDEF
CLIENTROLE_GRDEF
CLIENTROLE_GROUP
CLIENTROLE_GROUP
CLIENTROLE_GROUP
CLIENTROLE_GROUP
CLIENTROLE_LOV
CLIENTROLE_LOV
AS_OF_DAY
CLIENTROLE_GK
CLIENTROLE_UK
JOB_INSERT
AS_OF_DAY
CNT
GK
JOB_INSERT
NAME
UK
Дата поступления или обновления записи в хранилище
Группа ролей контрагента
Роль контрагента
Идентификатор JOB’а, который вставил данную запись
Дата поступления или обновления записи в хранилище
Кол-во ролей в группе
Уникальный идентификатор группы
Идентификатор JOB’а, который вставил данную запись
Наименование роли контрагента
Унифицированный ключ
dMetaValidity
dCodeNum
dKey
dMetaJob
dMetaValidity
dQuantity
dKey
dMetaJob
dName
dKey
CLIENT_HDIM
CLIENT_HDIM
CLIENTROLE_GK
NAME
ID группы ролей контагента
Наименование контрагента (рус)
dKey
dName
CLIENT_HDIM
PIN
Код ПИН/БИН контрагента из справочника EQ.CIF (для
объединенных контрагентов PIN EQ перечисляется через
запятую)
dCodeChar
CLIENT_HDIM
UK
Унифицированный ключ
dKey
Историчность по группе не ведется.
При изменении состава группы создается новая группа
Таблица, использующая группу изменяется в соответствии с
типом ведения историчности для данной таблицы

23.

Группы – (*_GROUP и *_GRDEF)
Аналогия связи сущностей с применением
классической ассоциации
CLIENT
CLIENT2ROLE_VHIST
UK
Наименование
Клиент
Роль
UK
Наименование
1
Иванов
Иванов
Клиент
1
Клиент
2
Петров
Петров
Клиент
2
VIP
3
Сидоров
Петров
VIP
3
Поручитель
Сидоров
Поручитель
…
n
Яковлев
Миллионы записей
CLIENTROLE
…
Яковлев
Клиент
Яковлев
Поручитель
Миллионы записей
Десятки записей

24.

Группы – (*_GROUP и *_GRDEF)
Тот же самый пример с использованием групп
CLIENT
CLIENTROLE_GK
CLIENTROLE_GRDEF
CLIENTROLE
GK
Роль
UK
Наименование
UK
Наименование
1
Иванов
1
1
Клиент
1
Клиент
2
Петров
2
2
Клиент
2
VIP
3
Сидоров
3
2
VIP
3
Поручитель
3
Поручитель
…
n
Яковлев
Миллионы записей
4
…
4
Клиент
4
Поручитель
Десятки записей
Десятки записей

25.

Размерности DWSSRC, DWSESRC
Размерность DWSSRC содержит список всех источников данных, которые
используются при загрузке Ядра DWH и формировании витрин данных.
Ядро DWH является источником данных для витрин и также заносится в DWSSRC.
Под источником данных понимается программный комплекс (либо отдельный экземпляр ПК), являющийся источником
информации для DWH. Каждый экземпляр ПК рассматривается как самостоятельный источник данных. Фактически,
каждая запись в данной размерности отражает экземпляр и сервер, с которого приходят данные.
Имя столбца
Домен
Описание
DWSSRC
dKey
Уникальный код (ID) источника данных
SRC_NAME
dDescription
Название источника данных
SRC_SCHEMA
dDescription
Название схемы в Staging DWH
DWSPRIORITY
dNumeric
«Глобальный» приоритет источника данных. Используется для
весового алгоритма унификации атрибутов.
Размерность DWSESRC содержит список таблиц в каждом источнике данных.
Имя столбца
DWSEID
DWSSRC
EID_NAME
EID_ORIGINAL
Домен
dKey
dKey
dDescriprion
dDescriprion
Описание
Уникальный код (ID) таблицы-источника.
Уникальный код источника данных
Название таблицы в Staging DWH
Название таблицы в источнике данных

26.

Размерность DWSEMIX
Размерность DWSEMIX содержит все возможные сочетания идентификаторов
таблиц (DWSEID) источников данных, используемых для формирования атрибутов
итоговой сущности.
Эта размерность уникальна по сочетанию DWSEMIX – DWSEID. На каждое значение DWSEMIX приходится одно
или несколько значений DWSEID. Количество этих значений отражается в DWSECNT.
Первые 10000 (с DWSEMIX < 10000) записей в этой таблице зарезервированы для сочетаний, соответствующих
одной таблице источника данных (для таких записей DWSEMIX=DWSEID и DWSECNT=1).
Имя столбца
DWSEMIX
Домен
dKey
DWSEID
DWSECNT
dKey
dNumeric
Описание
Уникальный код (ID) сочетания идентификаторов таблиц источников
данных
Уникальный код таблицы источника данных
Количество таблиц в данном сочетании DWSEMIX

27.

Пример использования DWSEMIX
DWSSRC
DWSSRC
SRC_NAME
1
ODS
2
EQ
DWSEMIX
DWSESRC
DWSEMIX
DWSEID
DWSECNT
1
1
1
2
2
1
…
…
….
DWSEID
EID_NAME
DWSSRC
1565
1
3
1
GF2PF
1
1565
2
3
2
IB_ISSUERS
1
1565
3
3
3
IB_OWNERS
1
2636
2
2
4
SV2PF
1
2636
3
2
3474
2
2
3474
4
2
…
…
…
IB_ISSUERS
GF2PF,
IB_ISSUERS,
IB_OWNERS
GF2PF,
SV2PF
CLIENT_HDIM
UK
ФИО
Город
EMIX
5213
Иван Иванович Иванов
Тверь
1565
7457
Борис Борисович Борисов
Вологда
3474
9829
Игнат Игнатович Игнатов
Сызрань
2
Информация по клиенту загружена из
GF2PF, IB_ISSUERS, IB_OWNERS
Информация по клиенту загружена из
GF2PF, SV2PF
Информация по клиенту загружена
только из IB_ISSUERS

28.

X
X
X
X
X
UNIUPDATE
UNIMAN
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
HSRC
UNITODO
X
X
X
GSRC
SDELTA
X
X
X
FSRC
UKLINK
X
X
X
WDELTA
CDELTA
X
X
X
Интерфейс
DSRC
X
X
X
X
Интер.
Staging
DWH
DELTA
X
*
*
*
X
X
CONTEXT
X
DWSEMIX
X
X
X
X
X
X
X
X
X
X
X
X
VALUE_DAY
X
X
X
X
AS_OF_DAY
DEFAULT_FLAG
X
X
X
X
X
X
Staging DWH
NKLINK
X
X
DELETED_FLAG
*
*
*
*
*
X
X
X
X
X
VALIDFROM
GK
TK
XK
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
VALIDTO
X
X
X
X
X
JOB_UPDATE
Подтип
LOV
LDIM
SDIM
HDIM
XDIM
VHIST
TRAN
HTRAN
STAT
HSTAT
GROUP
GRDEF
JOB_INSERT
Тип
Dimension
Dimension
Dimension
Dimension
Dimension
Fact
Fact
Fact
Fact
Fact
Group
Group
UK
Метаданные презентационного слоя
NK
Тип таблицы
MIRROR
Метаданные Ядра DWH
X
X
X
X
X
X
X
X

29.

Контроль качества данных
Цели:
Обеспечить высокое качество данных
Обеспечить обратную связь с исходными системами (в форме
сообщений, идентифицирующих проблемные записи)
Обеспечить возможность проверки (аудита) данных в хранилище
данных (для каждого атрибута должен существовать точно
определенный источник происхождения, так называемая исходная
система, или правило, на основе которого он был вычислен)
Мониторинг процесса проверки качества данных на каждом уровне
загрузки
Своевременное оповещение о наличии некачественной информации
и оперативное принятие решения о перерасчете/корректировке данных
на любом из уровней загрузки информации.

30.

Контроль качества данных
Средства контроля качества данных:
On-line проверки
Off-line проверки
Отчеты по качеству данных

31.

Витрины Данных
П
Ринформацию,
Е
О
Б
Р
А
1. Содержат
Извлечение, Выделение дельты,
Маппинг приложений, Унификация
обогащенную
и агрегированную
записей, Преобразование ключей, Унификация артрибутов, История
под задачи конкретной
предметной области
З
О
BI-специфические
преобразования
Data Warehouse
СистемыSource
источники
2. Могут
хранить как Staging Ядро DWH
Виртуальное Ядро DWH
(Представления детальных
данных)
AlfaFactoring, AlfaLeasing,
DBO, ..)
5. Возможны периодические
Приложения РБ:
(GEMINI, SLOLP RB,
перегрузки,
пересчеты
SLOLP CF, SLOLP AK,
SLOLP MG, WSRM, CCM,
агрегатов
DM на основе
DebtManager, ПО Legal,
PDS, Credit Dossier,
детальных
данных Ядра DWH
Smart Vista, ..)
Staging
DM RWA
(Детальные данные МСФО)
Я
Бизнеспользоват ели
Вн ешние
системы
системы)
DM ФБ
Отчетность
ФБ
DM ФО
DM Экспорт
в KRM
KRM
Отчетность
КБ
DM
ФВ RWA
CRM
BMB
Staging
DM КБ
DM КБ
Staging
DM Казн.
DM
Казн-во
Отчетность
Казначейства
Loan
Manager
MGR
DM РБ
Перенос
Staging «Ядра DWH»
Интерфейсный уровень Staging
Интерфейсный уровень
Область выгрузки
4. Глубина хранения –
минимально необходимая
КБ:
для Приложения
решения
задач BI
(LoanManager,
Приложения
Казначейства (БД
Фондирование,
администратор ставок)
И
Oracle BI
Система
Коррекций
Staging DM ФО
Данные ДАБов
ПО Холдинга
3. Модель
хранения –
Система интерфейсов
оптимизирована
под
ручного ввода
использование
конкретным BI и
Приложения
инвестиционного Блока
обеспечение
(FOCUS,OPICS,SMART, ) скорости
выполнения
аналитических
Приложения
коммерческого Блока
(Credit, SalesLogix, СКС,
запросов
Вексельный Центр, ...)
Н
Отчет-специфические
преобразования
«Бизнес-ET L», «Бизнесметаданные»
Слой
синхронизации
Staging DM РБ
ODS
детальные,
так и
агрегированные
данные
АБС EQUATION
А
Business Intelligence
BI Front Ends
DataMarts
(Аналитические
DWH
Ядро DWH
(Хранимые детальные данные РСБУ)
Integration
В
Staging
DM ACRM
DM
ACRM
Staging
DM Coll-n
DM
Collection
Staging
DM УРР
DM
УРР
Staging
DM PL
DM PL
Staging
DM PR
DM PR
Кредитный
портфель
Системы
потребители
Отчетность
Collection
Отчетность для
ОперБлока
Отчетность для
прочих Блоков
Отчетность Витрины
процессов
Потоки обмена данными
Системы
потребители
DM BUS
Job M anagement, Метаданные Informatica
Централизованный Репозитарий Метаданных
Системы
потребители
Метаданные BI

32.

Структуры данных Ядра и Конечные витрин
Ядро
DWH
Конечные
витрины
Нормализованные Денормализованные
структуры
структуры
по типу «2,3 NF».
по типу «Звезда».
Детальные данные.
Агрегированные данные.

33.

Структуры данных Ядра (3NF)
Клиенты
Остатки по счетам
Счета
Проводки
Счета сделок
Сделки
Типы сделок
Продукты
Размерности
Факты
Признак
привлечения\
размещения
продукта
Ассоциации
Списки значений LOV

34.

Ядро DWH. Справочник продуктов
PRODUCT_HDIM (Продукты)
UK
PARENT_UK
CCODE
NAME
PRODUCTTYPE_UK
…
Ключ
Ccылка на
родителя
Символь
ный код
Наименование продукта
Признак привлечения /
размещения продукта
…
PRODUCTTYPE_LOV
(Признак привлечения/
размещения продукта)
UK
NAME
1
NULL
01
Кредиты
2
…
Ключ
Наименование
2
NULL
02
Депозиты
1
…
-1
Неверное значение
3
1
01.01
Кредиты ФЛ
2
…
0
Не определено
4
3
01.01.01
Потребительский кредит
2
…
1
Привлечение
5
2
02.01
Депозиты ФЛ
1
…
2
Размещение
6
5
02.01.01
Срочный депозит
1
…

35.

Аналитические запросы к Ядру
Пример вычисления доходности по продукту по структурам Ядра DWH
SELECT
[Продукты 3-го уровня].[UK Продукта],
[Продукты 3-го уровня].[Код продукта],
[Продукты 3-го уровня].[Наименование],
[Продукты 2-го уровня].[Код продукта],
[Продукты 1-го уровня].[Код продукта],
SUM([Обороты по сделке].[Доход]),
SUM([Обороты по сделке].[Расход])
…
FROM
[Сделки]
INNER JOIN
[Продукты] AS [Продукты 3-го уровня]
ON [Продукты 3-го уровня].[UK Продукта] = [Сделки].[UK Продукта]
INNER JOIN
[Продукты] AS [Продукты 2-го уровня]
ON [Продукты 2-го уровня].[UK Продукта] = [Продукты 3-го уровня].[PARENT_UK]
INNER JOIN
[Продукты] AS [Продукты 1-го уровня]
ON [Продукты 1-го уровня].[UK Продукта] = [Продукты 2-го уровня].[PARENT_UK]
LEFT OUTER JOIN
(
SELECT
[Счета сделок].[ID Сделки],
SUM([Остатки по счетам].[Остаток]),
…
FROM
[Счета сделок]
INNER JOIN
[Остатки по счетам]
WHERE
…
GROUP BY
[Счета сделок]. [ID Сделки]
) AS [Остатки по сделке]
ON [Остатки по сделке].[ID Сделки] = [Сделки].[ID Сделки]
LEFT OUTER JOIN
(
SELECT
[Счета сделок].[ID Сделки]
SUM([Проводки].[Сумма]),
…
FROM
[Счета сделок]
INNER JOIN
[Проводки]
WHERE
[Проводки].[Дата проводки] >= [Дата С] AND
[Проводки].[Дата проводки] < [Дата ПО]
GROUP BY
[Счета сделок]. [ID Сделки]
) AS [Обороты по сделке]
ON [Обороты по сделке].[ID Сделки] = [Сделки].[ID Сделки]
INNER JOIN
[Признак привлечения\размещения продукта]
ON ([Признак привлечения\размещения продукта].[UK] =
[Продукт].[Признак привлечения\размещения продукта])
WHERE
[Признак привлечения\размещения продукта].[Наименование] =
‘Размещение’
GROUP BY
[Продукты 3-го уровня].[UK Продукта],
[Продукты 3-го уровня].[Код продукта],
[Продукты 3-го уровня].[Наименование],
[Продукты 2-го уровня].[Код продукта],
[Продукты 1-го уровня].[Код продукта]
...

36.

Структуры данных конечных витрин (Star)
Клиенты
Сделки
Продукты
Метрики
продуктов Банка
Типы сделок
Признак
привлечения\
размещения
продукта

37.

Денормализация данных на витринах
Витрина
PRODUCT_L3_SDIM (Продукты 3-го уровня)
UK
L1_CCODE
L2_CCODE
L3_CCODE
L3_NAME
PRODUCTTYPE_NAME
Ключ
Символьный
код продукта
1-го уровня
Символьный
код продукта 2го уровня
Символьный
код продукта 3го уровня
Наименование
продукта 3-го уровня
Наименование признака
привлечения \ размещения
продукта
4
01
01.01
01.01.01
Потребительский
кредит
Размещение
6
02
02.01
02.01.01
Срочный депозит
Привлечение
PRODUCTPROFIT_SAGG (Метрики продуктов Банка)
VALUE_DAY
PRODUCT_UK
PROFIT_TD_RUR_AMT
PROFIT_LW_RUR_AMT
PROFIT_LM_RUR_AMT
Бизнес-дата
Ссылка на
продукт
Прибыль на бизнес дату
Прибыль на
аналогичный день
прошлой недели
Прибыль на аналогичный день
прошлого месяца
01.12.2010
4
12345.45
10456.56
8234.09
01.12.2010
6
34343.67
32456.98
25067.03
02.12.2010
4
11278.33
9876.76
9500.78
02.12.2010
6
33478.23
31567.53
28068.72

38.

Аналитические запросы к Витринам
Пример вычисления доходности по продукту по структурам Витрин
SELECT
[Продукты 3-го уровня].[UK Продукта],
[Продукты 3-го уровня].[Код продукта 3-го уровня],
[Продукты 3-го уровня].[Наименование продукта 3-го уровня],
[Продукты 3-го уровня].[Код продукта 2-го уровня],
[Продукты 3-го уровня].[Код продукта 1-го уровня],
[Продукты 3-го уровня].[Признак привлечения\размещения],
[Метрики продуктов Банка].[Прибыль на бизнес-дату]),
[Метрики продуктов Банка].[Прибыль на аналогичный день прошлой недели]),
[Метрики продуктов Банка].[Прибыль на аналогичный день прошлого месяца]),
...
FROM
[Продукты]
INNER JOIN
[Метрики продуктов Банка]
ON ([Метрики продуктов Банка].[UK Продукта] = [Продукты].[UK])
WHERE
[Продукты 3-го уровня].[Признак привлечения\размещения] = ‘Размещение’ AND
[Метрики продуктов Банка].[Бизнес дата] >= [Дата С] AND
[Метрики продуктов Банка].[Бизнес дата] < [Дата ПО]
...

39.

Витрины данных
Основные принципы построения витрин
Источник данных для витрин – ядро или другая витрина
Исключением из этого правила могут являться настроечные таблицы, посредством которых выполняется управление
механизмом загрузки и lookup таблиц, которые непосредственно в отчетах не используются
Для промежуточного хранения данных в ходе загрузки
используются staging области витрин
Модель хранения данных в витринах оптимизирована для
выборки данных
При использование общих данных несколькими витринами –
организуются общие промежуточные витрины
При необходимости в витрине сделать drilldown к детальным
данным можно делать это одним из двух способов:
1) путем ETL требуемых детальных данных в витрину
(например, для глубокого ad-hoc анализа данных);
2) доступ к детальным данным Ядра или других витрин
детальных данных через dblink, view или synonym,
если при этом не предполагается ad-hoc анализа данных.

40.

Метаданные презентационного уровня

41.

Метаданные презентационного уровня
Наименование атрибута
Domain name
Описание
NK
dKey
Суррогатный ключ
UK \ DK
dKey
Унифицированный ключ
XK
dKey
Уникальный идентификатор записи
GK
dKey
Первичный ключ - идентификатор группы
TK
dTextKey
Первичный ключ факта
VALUE_DAY
dActuality
Бизнес-дата факта
EFFECTIVE_FROM /_TO
dActuality
Бизнес период факта
JOB_INSERT
dMetaJob
Идентификатор JOB’а, который вставил данную запись
JOB_UPDATE
dMetaJob
Идентификатор JOB’а, который обновил данную запись
VALIDFROM
dMetaValidity
Действует с
VALIDTO
dMetaValidity
Действует по
DELETED_FLAG
dMetaDeleted
Признак удаления записи
DEFAULT_FLAG
dMetaDefault
Признак записи, введенной в хранилище для поддержания
ссылочной цельности
AS_OF_DAY
dMetaValidity
Дата поступления или обновления записи в хранилище
EMIX
dMetaSource
Код сочетания исходных таблиц
VER_ID
dMetaVersion
Идентификатор версии
PK
dKey
Первичный ключ ручной таблицы
DELETED_FLAG
dMetaDeleted
Признак удаления записи
UPDATE_DATE
dMetaTimestamp
Таймштамп создания или изменения записи
AUTHOR_UPDATE_NAME
dMetaLogin
Логин Active Directory (AD) пользователя, создавшего или
изменившего запись
ETL-таблицы
Ручные таблицы DWDICT\СК

42.

Первичные ключи на витринах
Первичные ключи таблиц на Витринах формируются
на основе первичных ключей Ядра Хранилища
генерируются при загрузке витрин по правилам, аналогичным
таковым для Ядра
Если ключ, идентифицирующий версии одной сущности на уровне витрин в
точности соответствует ключу, используемому для этих целей на ядре, то
этот ключ продолжает именоваться UK
Если ключ, идентифицирующий версии одной сущности на уровне витрин
не соответствует таковому на уровне ядра (размерность витрины
получается путем сложных трансформаций из размерностей ядра или
размерность появляется только на уровне витрины), то такой ключ следует
именовать DK

43.

Обеспечение историчности на витринах
Подходы по поддержке историчности, применяемые на витринах
Для размерностей:
Без поддержки историчности
С применением технической истории (как в Ядре DWH)
Перенос историзуемых атрибутов размерности в таблицу фактов
Для фактов:
Без поддержки историчности
С применением технической истории (как в Ядре DWH)
Для агрегатов:
Без поддержки историчности
С применением технической истории

44.

Хранение агрегированных данных
Для хранения агрегированных данных используются
следующие типы таблиц:
SAGG – для агрегатов без поддержки истории.
Структура должна применять для хранения единственного актуального среза
агрегированных данных.
HAGG – для агрегатов с технической историей.
Структура должна применяться в случаях необходимости хранения
агрегированных данных за произвольные периоды и в случае инкрементальной
загрузки агрегатов.

45.

Метаданные таблиц агрегатов
Тип
сущности
SAGG
Наименование атрибута
Domain name
Комментарий
XK
JOB_INSERT
JOB_UPDATE
AS_OF_DAY
EMIX
dKey
dMetaJob
dMetaJob
dMetaValidity
dMetaSource
Первичный ключ агрегата
Идентификатор JOB’а, который вставил данную запись
Идентификатор JOB’а, который обновил данную запись
Дата и время поступления записи в хранилище
Уникальный код сочетания идентификаторов таблиц, по
данным которых формировался агрегат.
HAGG
XK
VALIDFROM
VALIDTO
JOB_INSERT
JOB_UPDATE
AS_OF_DAY
EMIX
dKey
dMetaValidity
dMetaValidity
dMetaJob
dMetaJob
dMetaValidity
dMetaSource
Первичный ключ агрегата
Дата занесения записи в хранилище
Дата удаления записи из хранилища
Идентификатор JOB’а, который вставил данную запись
Идентификатор JOB’а, который обновил данную запись
Дата и время поступления записи в хранилище
Уникальный код сочетания идентификаторов таблиц, по
данным которых формировался агрегат.

46.

Значения метрик относительно даты факта
Суффикс
_LD
_LW
_LM
_LY
_LQ
Суффикс
_TD
Описание
Прошедший день
Аналогичный день прошлой недели
Аналогичный день прошлого месяца
Аналогичный день прошлого года
Аналогичный день прошлого квартала
_BM
Описание
Значение на дату факта (today)
(Опционально) в случае отсутствия суффикса, следует считать, что значение
зафиксировано на дату факта
Значение на начало месяца относительно даты факта (begin of month)
_EM
Значение на последний день месяца относительно даты факта (end of month)
_MM
Значение на 15-е число месяца относительно даты факта (middle of month)
_BW
Значение на начало недели относительно даты факта
_EW
Значение на конец недели относительно даты факта
_BQ
Значение на начало квартала относительно даты факта
_EQ
Значение на конец квартала относительно даты факта

47.

Агрегирующие функции в полях таблиц фактов
Агрегирующая функция
Сумма
Среднее
Минимальное значение за период
Максимальное значение за период
Количество
Период агрегации
today
last calendar day
last week
last calendar month
last calendar year
rolling week
rolling month
rolling quarter
rolling year
current week
current month
current quarter
current year
Суффикс
_SUM
_AVG
_MIN
_MAX
_CNT
Суффикс
_TD
_LD
_LW
_LM
_LY
_RW
_RM
_RQ
_RY
_CW
_CM
_CQ
_CY

48.

Пример: ежемесячный агрегат остатков по счетам:
VALUE_DAY
CLIENT_UK REST_BM_RUR_AMT
TURN_LM_RUR_AMT
REST_L4M_AVG_RUR_AMT
EXCHANGE_MM_RATE
REST_BM_RUR_AMT
- остаток по счету на начало месяца (суффикс “_BM”)
TURN_LM_RUR_AMT
- оборот по счету за прошлый месяц (суффикс “_LM”)
REST_L4M_AVG_RUR_AMT
- средний остаток за последние 4 месяца (суффикс “_L4M_AVG”)
EXCHANGE_MM_RATE
- обменный курс на середину месяца (суффикс “_MM”)

49.

Способы хранения показателей
В ряде случаев в одном отчете могут комбинироваться самые разные метрики (планы и факты,
различные виды взносов по кредитам и т.п.)
В качестве альтернативы хранения каждой метрики в отдельном поле, можно использовать подход
при котором для метрик в таблице фактов отводится фиксированный набор полей
Размерность “CLIENT_SDIM”
UK
091
756
892
..
Фамилия
Иванов
Петров
Смирнов
...
Семейное положение
Женат
Женат
Холост
...
N паспорта
66 89 4567
33 89 4544
87 98 0985
...
...
...
...
...
...
AS_OF_DAY
13.05.2010
13.06.2010
13.06.2010
...
Факты по кредитам
VALUE_DAY
CLIENT_UK
13.05.2010
13.06.2010
...
091
091
...
...
...
...
...
METRICVALUE1
METRICTYPE1_UK
2000
2500
...
1
2
...
Размерность “Тип метрики” - Metrictype
UK
1
2
3
..
Тип метрики
Погашение основного долга
Погашение %
Погашение просроченной задолженности по %
...

50.

Глубина хранения данных на витринах
Детализация
данных
Дневная
Недельная
Месячная
Годовая
Срок хранения
12 полных месяцев от текущей
даты
24 полных месяцев от текущей
даты
3 года (36 полных месяцев от
текущей даты)
бесконечно

51.

Система редактирования ручных справочников
Система редактирования ручных справочников
Тонкий клиент
IE/Windows
HTTP
Ручной ввод
или импорт XLS
Серверное
приложение
«Редактор
справочников»
WAS/HP-UX(Linux)
JDBC
БД «Редактор
справочников»
Oracle 10g
Ответственный
сотрудник
Data Warehouse
Staging DWH
Business Intelligence
Ядро DWH
Staging DM
DataMarts
Настроечные
таблицы и
BRIDGE-ы
...
Взаимодействие
ETL справочников
ETL настроек
Запросы данных
DWH
Oracle 10g
Staging
DM ФО
...
DM ФО
...

52.

Именование ссылок
ТАБЛИЦА_[УТОЧНЕНИЕ]_КЛЮЧ
CLIENT_AA_UK
Ссылка на клиента по управленческому учету
CLIENT_SDIM
Таблица размерности
AA
Administrative Accounting
UK
Унифицированный ключ CLIENT_SDIM
dForeignKey, NUMBER, NULL = N

53.

Ссылки на таблицы фактов
ТАБЛИЦА_[УТОЧНЕНИЕ]_КЛЮЧ
PAYMENTDOCUMENT_AA_TK
Ссылка на платежный документ
PAYMENTDOCUMENT_AA_VALUE_DAY
PAYMENTDOCUMENT_STRAN
Таблица факта
AA
Administrative Accounting
TK
Текстовый ключ PAYMENTDOCUMENT_STRAN
VALUE_DAY
PAYMENTDOCUMENT_STRAN,
*_TK
Бизнес-дата
(ключ партиционирования)
- dForeignTextKey, VARCHAR2(n), NULL = N
*_VALUE_DAY - dForeignActuality, DATE, NULL = N

54.

ДЕНЕЖНЫЕ СУММЫ
Правило
Денежная сумма
выражена в
фиксированной валюте
Денежная сумма
выражена в
настраиваемой валюте
Шаблон
[Описание_]<Код ISO валюты>_AMT
Примеры
RUR_AMT, SOME_USD_AMT,
ANOTHER_EUR_AMT
CURRENCY_[<Определитель
валюты>_]UK
CURRENCY_UK, CURRENCY_SELL_UK,
CURRENCY_BUY_UK
[Описание_]<Определитель валюты>_AMT CUR_AMT, SELL_AMT, BUY_AMT,
SOME_SELL_AMT, ANOTHER_SELL_AMT,
SOME_BUY_AMT, ANOTHER_BUY_AMT,
OTHER_MARK_CUR_AMT
*_AMT - dAmount, NUMBER, NULL = Y

55.

ДЕНОРМАЛИЗАЦИЯ
Крупная
Факт
VIEW
UK
CODE
Мелкие
UK
CODE
NAME
UK
CODE
NAME
NAME
UK
XK
XK
XK
CODE
NAME
Мелкие
CODE
UK
NAME
CODE
NAME
Факт
Крупная
Факт
TABLE
CODE
NAME
CODE
CODE
NAME
NAME
UK
CODE
NAME

56.

Спасибо за внимание!