|
|
|
Что это - таблица фактов или измерений? Или такому в DWH не место?
|
|||
|---|---|---|---|
|
#18+
Из другой системы приходят данные типа: 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.08.2020, 23:54 |
|
||
|
Что это - таблица фактов или измерений? Или такому в DWH не место?
|
|||
|---|---|---|---|
|
#18+
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.08.2020, 08:25 |
|
||
|
Что это - таблица фактов или измерений? Или такому в DWH не место?
|
|||
|---|---|---|---|
|
#18+
Charles Weyland, если у Вас цель сделать это все на SSAS MD, то никакой сложности я здесь не вижу. это анализ данных под кодовым названием "In Flight" (увидел у кого-то давным давно этот термин, понравился) основан на m2m проектов с таблицей возможных диапазонов. результат примерно такой (в месте где стоит 1, там может быть любая мера, у меня в реальности объем продаж по акциям): ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2020, 13:15 |
|
||
|
Что это - таблица фактов или измерений? Или такому в DWH не место?
|
|||
|---|---|---|---|
|
#18+
предыдущий пример немного не показателен, там разные иерархии одного измерения ниже дата и сроки акций - это разные измерения: ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2020, 13:20 |
|
||
|
Что это - таблица фактов или измерений? Или такому в DWH не место?
|
|||
|---|---|---|---|
|
#18+
Спасибо за комментарии! До меня, кажись, дошло. Правильно ли я понимаю, что должно быть так: 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.08.2020, 21:41 |
|
||
|
|

start [/forum/topic.php?fid=49&tid=1857270]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
58ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
2ms |
| others: | 11ms |
| total: | 160ms |

| 0 / 0 |
