Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / OLAP и DWH Новый топик    Ответить
 Что это - таблица фактов или измерений? Или такому в DWH не место?  [new]
Charles Weyland
Member

Откуда: Feorina "Fury" 161
Сообщений: 4350
Из другой системы приходят данные типа:

tbl_Projects
Проект А Дата/время начала Дата/время завершения Категория тип исполнитель т.д.

но "tbl_" в DWH быть не может. Там либо fact_, либо dim_
Поэтому вопрос №1: tbl_Projects - это таблица фактов или измерений? Или такого типа таблицам (с диапазонами "от/до" вместо выбранной чёткой гранулярности данных) вообще не место в DWH?

Да и куб по этой таблице построить невозможно. Нужно из неё обязательно делать таблицу-измерение.
Вот и делаю таблицу fact_Projects, которая, как просил бизнес, с гранулярностью до месяца, ибо "больше не надо".
Проект Дата Услуга Тип Исполнитель Сумма
Проект А 1.01.2020 ... ... ... ...
Проект Б 1.01.2020 ... ... ... ...
Проект А 1.02.2020 ... ... ... ...
Проект В 1.02.2020 ... ... ... ...
......... ... ... ...

Почему "fact_", так потому что там есть числовые данные.

Вопрос №2: Как методологически правильно сделать - отдельную базу типа "DataLake", в которой будут исходные данные, и уже от неё витрины, или хранить tbl_Projects и fact_Projects прямо в одной базе?

Эх, видать, всё ж придётся читать мне толстые книжки кроссоверы "Кимбалл против Инмон".
19 авг 20, 23:54    [22184720]     Ответить | Цитировать Сообщить модератору
 Re: Что это - таблица фактов или измерений? Или такому в DWH не место?  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4806
Charles Weyland,

Для начала посмотрите, что такое по определению "Таблица Фактов". То что вы показываете таблицей фактов не является. Полям вида "Проект А" в таблице фактов не место.

Вам надо выполнить процесс под названием Dimational Modeling.

Dimensional modeling (DM) is part of the Business Dimensional Lifecycle methodology developed by Ralph Kimball which includes a set of methods, techniques and concepts for use in data warehouse design.[1]:1258–1260[2] The approach focuses on identifying the key business processes within a business and modelling and implementing these first before adding additional business processes, a bottom-up approach.[1]:1258–1260

Designing the model
The dimensional model is built on a star-like schema or snowflake schema, with dimensions surrounding the fact table.[3][4] To build the schema, the following design model is used:

Choose the business process
Declare the grain
Identify the dimensions
Identify the fact

Choose the business process
The process of dimensional modeling builds on a 4-step design method that helps to ensure the usability of the dimensional model and the use of the data warehouse. The basics in the design build on the actual business process which the data warehouse should cover. Therefore, the first step in the model is to describe the business process which the model builds on. This could for instance be a sales situation in a retail store. To describe the business process, one can choose to do this in plain text or use basic Business Process Modeling Notation (BPMN) or other design guides like the Unified Modeling Language (UML).

Declare the grain
After describing the business process, the next step in the design is to declare the grain of the model. The grain of the model is the exact description of what the dimensional model should be focusing on. This could for instance be “An individual line item on a customer slip from a retail store”. To clarify what the grain means, you should pick the central process and describe it with one sentence. Furthermore, the grain (sentence) is what you are going to build your dimensions and fact table from. You might find it necessary to go back to this step to alter the grain due to new information gained on what your model is supposed to be able to deliver.

Identify the dimensions
The third step in the design process is to define the dimensions of the model. The dimensions must be defined within the grain from the second step of the 4-step process. Dimensions are the foundation of the fact table, and is where the data for the fact table is collected. Typically dimensions are nouns like date, store, inventory etc. These dimensions are where all the data is stored. For example, the date dimension could contain data such as year, month and weekday.

Identify the facts
After defining the dimensions, the next step in the process is to make keys for the fact table. This step is to identify the numeric facts that will populate each fact table row. This step is closely related to the business users of the system, since this is where they get access to data stored in the data warehouse. Therefore, most of the fact table rows are numerical, additive figures such as quantity or cost per unit, etc.

https://en.wikipedia.org/wiki/Dimensional_modeling
Ralph Kimball; Margy Ross; Warren Thornthwaite; Joy Mundy (10 January 2008). The Data Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing, and Deploying Data Warehouses (Second ed.). Wiley. ISBN 978-0-470-14977-5.
20 авг 20, 08:25    [22184779]     Ответить | Цитировать Сообщить модератору
 Re: Что это - таблица фактов или измерений? Или такому в DWH не место?  [new]
ShIgor
Member

Откуда: Нижний Новгород
Сообщений: 2355
Charles Weyland,

если у Вас цель сделать это все на SSAS MD, то никакой сложности я здесь не вижу.
это анализ данных под кодовым названием "In Flight" (увидел у кого-то давным давно этот термин, понравился)
основан на m2m проектов с таблицей возможных диапазонов.
результат примерно такой (в месте где стоит 1, там может быть любая мера, у меня в реальности объем продаж по акциям):

К сообщению приложен файл. Размер - 119Kb
20 авг 20, 13:15    [22184919]     Ответить | Цитировать Сообщить модератору
 Re: Что это - таблица фактов или измерений? Или такому в DWH не место?  [new]
ShIgor
Member

Откуда: Нижний Новгород
Сообщений: 2355
предыдущий пример немного не показателен, там разные иерархии одного измерения
ниже дата и сроки акций - это разные измерения:

К сообщению приложен файл. Размер - 81Kb
20 авг 20, 13:20    [22184930]     Ответить | Цитировать Сообщить модератору
 Re: Что это - таблица фактов или измерений? Или такому в DWH не место?  [new]
Charles Weyland
Member

Откуда: Feorina "Fury" 161
Сообщений: 4350
Спасибо за комментарии!

До меня, кажись, дошло.

Правильно ли я понимаю, что должно быть так:

DIM_Projects
IDNameDateFromDateTo сумма контракта
171 Проект А Дата/время начала Дата/время завершения 175000 Категория тип исполнитель т.д.
172 Проект А Дата/время начала Дата/время завершения 170000 Категория тип исполнитель т.д.

("сумма" здесь присутствует только к сведению и не подлежит вычислениям, ибо ведь это DIM_. У меня в проектах есть история изменений, поэтому хочу зафиксировать, в какой момент проект был в какой категории и с какой суммой)

FACT_Projects
ID ДатаKey Сумма контракта другие суммы
171 1.01.2020 175000 ... ... ...
180 1.01.2020 ... ... ... ...
171 1.02.2020 ... ... ... ...
199 1.02.2020 ... ... ... ...
......... ... ... ...


Т.е. в данном случае ETL сначала дополняет таблицу DIM, а после этого пересобирает (полностью или частично) таблицу fact с заданным grain из таблицы dim.
А в dim может быть и история ведения проекта, и куча членов измерения и т.д. В fact попадают только числа двух типов: либо ключи, либо значения для агрегирования
20 авг 20, 21:41    [22185142]     Ответить | Цитировать Сообщить модератору
Все форумы / OLAP и DWH Ответить