Subject Model Advantage

After learning the subject model's principles, you may discover its advantages.

This document summarizes the advantages of the subject model.

No Need to Wait for Updates

After extracting data and performing Join, you need to click Save and Update to use the data table. If the table contains a large data volume, it will take much time to wait for the update completion.

However, once you establish the model association directly through the subject model, you can use the data table without waiting.

Easier Operation

When performing Join, you often need to choose Left Join or Right Join. If we make the wrong choice without understanding the table, it may lead to incorrect results.

However, through the subject model, you do not need to consider the merging method. You only need to establish connections and select matching fields. The system ensures data integrity in a more intelligent way.

Data Inflation Avoiding

Performing Join easily introduces redundant data, which results in duplicate rows in the result table, leading to incorrect total values obtained during the analysis.

When using the subject model, the system automatically aggregates and then merges, without causing data inflation issues.

More Analysis Scenarios Supported, Simpler Data Processing, and Strengthened Association and Linkage Between Components

For example, you have established a model association for Product Table, Client Table, Order Table, and Salesperson Table.

If you want to analyze the sales performance of each salesperson, you can directly obtain salesperson information from Salesperson Table and sales order data for each salesperson from Order Table through the model.

If you want to analyze the purchasing situation of clients across different products, you can obtain customer information from Client Table and get order and product data from Product Table and Order Table respectively through the model.

If the above analyses utilize Join, multiple Join operations are required.

Besides, you need to notice data inflation. If there is data inflation, directly merging into one large wide table for analysis may be problematic. You can solve this problem by grouping and summarizing first, and then performing Join. However, merging into multiple cross-reference tables to serve different analysis components leads to many problems:

You will be bothered to perform summarizing by group and joining operations many times.

You will destroy the table structure. Summarizing by group makes the data granularity coarser, making the multi-level analysis cannot be conducted. For example, if you summarize data by Month, data at the Day granularity will be lost, making it inconvenient for later analysis at the Day level.

You will split components. Components that utilize different cross-reference tables as data sources cannot establish automatic linkage. However, the system can automatically establish the linkage between the components using the same subject model.

Better Support for the N:N Calculation Scenario

When you perform the Join operation, the N:N scenario produces a Cartesian product, which is not conducive to project stability. Besides, the data will multiply and inflate, making the calculation result may be incorrect.

However, the subject model can handle the N:N calculation very well, but note to choose the correct model structure. For details, see Official Recommendation for the Subject Model.

Data Extraction: Update Performance Improvement

The subject model is a logical connection that links the data of multiple tables through the code definition. It reduces the generation of cross-reference tables, saving storage space and update time.

Direct Data: Calculation Performance Improvement

With the premise of the analysis convenience, the subject model allows fewer data to be merged, improving calculation performance.

Only Merging Tables that Need to Be Merged

If there are ten tables in a subject model, the system will not merge all these tables. On the contrary, it will dynamically determine the tables to be merged based on the dimensions and indicators of the components dragged in, and only merge the used tables. After establishing the model, users can freely use the fields in these ten tables for analysis while also having efficient query performance, avoiding unnecessary data merging.

Performing Aggregation Before Merging

Assuming the original data table contains 100 million rows of data, and after the aggregation, there are only 1 million rows. In this case, the subject model, which aggregates first and then merges, can greatly reduce the to-be-merged data amount and significantly improve performance.

Bi-Directional Linkage Filtering Between the 1-End Table and N-End Table Supported

Most BI products on the market only support 1-end table to N-end table linkage filtering, while the subject model can achieve bidirectional linkage between 1-end table and N-end table.

For example, use the N-end table to create Sales of Different Contract Types and the 1-end table to create Customer Information, as shown in the following figure.

In this case, if you want to see which customers purchase A, you need to perform the linkage filtering on the 1-end table with the N-end table. Click the A column to filter out the corresponding customers.

Support the Calculation Indicator Reusing

You cannot reuse calculation fields from other components in the component in FineBI 5.0, and you need to create each component separately.

FineBI 6.0 introduces the subject model, realizing the reuse of calculation fields and parameters. In all components within the same analysis subject, the calculation fields and parameters defined in the to-be-analyzed area can be directly used without duplicated creation, improving efficiency.

Support Parameters in Calculation Fields

In FineBI 5.0, you cannot use parameters in calculation fields.

Similarly, the subject model in FineBI 6.0 also supported the use of parameters in calculation fields.

Although the subject model is advanced, it has some flaws. You are advised to avoid using the subject model in the following cases:

1. The subject model cannot publish data to Public Data. If you need to publish data, use Join to process multiple tables.

2. Establishing the model is easy, but there is a relatively high understanding cost. To avoid misuse, you are advised to use Join before understanding the subject model well.

3. In some scenarios, there exists a limitation on the filtering of the subject model. For example, create a model: Two fact tables (Sales Volume Table and Purchase Table) share one dimension table (Product Table).

Assuming you add a filter component to filter Sales VolumeTable, and the filter component binds the Date field of Sales Volume Table.

When you filter out the data in 2022/5/1, only Milk was sold on that day. Then you also find that the purchase data table only has Milk left.

This is because after you filter Sales Volume Table, the filtering transfer is generated based on the matching field Product.

After the filter component filters, only Milk is left in Sales Volume Table, which is then transferred to Product Table and Purchase Table, causing you to only be able to see the Milk data when viewing the purchase data.

We will continue striving to improve and optimize the subject model to enhance its applicability and performance. We will listen to your feedback and demand, strive to conduct further research, and develop more advanced technologies to provide better multi-table analysis solutions. Meanwhile, you are encouraged to choose analysis methods and tools suitable for your needs and data characteristics in practical applications.