powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / Что это - таблица фактов или измерений? Или такому в DWH не место?
5 сообщений из 5, страница 1 из 1
Что это - таблица фактов или измерений? Или такому в DWH не место?
    #39990978
Charles Weyland
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Из другой системы приходят данные типа:

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 прямо в одной базе?

Эх, видать, всё ж придётся читать мне толстые книжки кроссоверы "Кимбалл против Инмон".
...
Рейтинг: 0 / 0
Что это - таблица фактов или измерений? Или такому в DWH не место?
    #39991027
Фотография a_voronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
...
Рейтинг: 0 / 0
Что это - таблица фактов или измерений? Или такому в DWH не место?
    #39991107
ShIgor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Charles Weyland,

если у Вас цель сделать это все на SSAS MD, то никакой сложности я здесь не вижу.
это анализ данных под кодовым названием "In Flight" (увидел у кого-то давным давно этот термин, понравился)
основан на m2m проектов с таблицей возможных диапазонов.
результат примерно такой (в месте где стоит 1, там может быть любая мера, у меня в реальности объем продаж по акциям):
...
Рейтинг: 0 / 0
Что это - таблица фактов или измерений? Или такому в DWH не место?
    #39991111
ShIgor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
предыдущий пример немного не показателен, там разные иерархии одного измерения
ниже дата и сроки акций - это разные измерения:
...
Рейтинг: 0 / 0
Что это - таблица фактов или измерений? Или такому в DWH не место?
    #39991246
Charles Weyland
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Спасибо за комментарии!

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

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

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 попадают только числа двух типов: либо ключи, либо значения для агрегирования
...
Рейтинг: 0 / 0
5 сообщений из 5, страница 1 из 1
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / Что это - таблица фактов или измерений? Или такому в DWH не место?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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