Change log past and present

Before changing log, we need to know its parent ODS (BI 7
Is called DSO ). ODS is like a commonTableAnd we often access ODS by reading its active
Data Table to obtain ODS data. Because we only understand the storage structure of data in ODS, we will not discuss other features of ODS.

As we mentioned above, an active data table. In fact, ODS-related data will be stored in three tables: New
Data Table stores data that has not been activated and is imported to ODS. Active Data Table
Store activated ODS data, and change log table stores data changes generated during activation. The naming rules for these three tables are as follows:
New data table:/BIC/A * 40 (System Description: Active Records)
Active Data Table:/BIC/A * 00 (System Description: Update)
Change log table: serial number
(The system description is transfer structure application 8 *)

* Indicates the specific ODS name.
So how can we understand the relationship between the three tables.
First, assume that an ODS is named zrl_001. Its structure is as follows:

Now let's load the data several times, from which we can see the change process of several tables.
Step 1: import a batch of data
Fiscper material amount currency
2010001 mat001 100 RMB
2010001 mat002 100 RMB
2010001 mat003 100 RMB

Data of each table:
/BIC/azrl_o0140: new data table

No data exists in the other two tables.
Then we activate the data.
At this time, the data in the new data table is cleared, and the data in the other two tables is as follows:
/BIC/azrl_o0100: Active Data Table

/BIC/b0004352000: change log table

From the changes in the tables above, we can only know for the moment that after activating the data, the new data table will be cleared and loaded to the other two tables. What is the loading logic? Since there is a log in the name, it naturally means a record. Then we load the following records to see how the data changes?
Fiscper material amount currency
2010001 mat001 100 RMB
2010001 mat002 200 RMB
2010001 mat003 300 RMB

It is necessary to predict the future before loading it. This is also a good thinking habit for programmers. We know that this ODS keyword has time and item number. Therefore, according to the characteristics of ODS, only one data row with the same time and item number can be stored when it stores a certain record. Therefore, after loading the latest data, it is obvious that the new and old keywords correspond one by one, that is, there are only three final records.
/BIC/azrl_o0140: new data table

After activation, the new data table is cleared. Let's look at the other two tables,
/BIC/azrl_o0100: Active Data Table

/BIC/b0004352000: change log table

We can understand the results of the Active Data Table table, because it stores the final record. Let's take a look at what happened to the change log.
1. The original three rows of data are changed to the current seven rows.
2. We uploaded a positive amount, but the amount of the two rows of records is negative.
3. We don't care about the data in the last column, but it seems very eye-catching and amazing.

First, let's look at the number of records added from three rows to seven rows. From the request column, we can see which 4 rows are added. In terms of keywords, they all appear in pairs. We don't care about the date because it is the same. So there are two records of mat002 and mat003. For clarity, I will take out three records of mat002 first.

We should know,There is no difference in record order, so we should not be confused by their order.In the second process, we changed the amount of mat002 to 200, and the previous number was 100. After a little pause, we will find that the system is giving us a primary computing class because 100
+ 200 + (-100) = 200 and this number is our final value. So,Change
Log table shows us a simple and practical zero-padding process.The above is just our self-righteousness, so does sap bw coincide with us?Let's go back to the section in the naming rule description. The system describes the change log table's "Transfer
Structure Application 8 * "(if you do not know what transfer structure is, check it elsewhere ). It was originally prepared as a data source, so it is not difficult to understand why zero is required. Because the data imported to other places is from the change log table (the premise is that the Delta mechanism is used to import data to other places ), assume that the original 100 is already in the cube, and now it will be changed to 200. Instead of doing a calculation first, 200-100 = 100, and then loading a 100, of course, I think it's okay to do this, because in terms of numerical values, that's the case, but why not, because I didn't find an official written explanation (I can't talk about it verbally ), we don't know. We can only roll back the results.
You should have known the first three questions, so let's take a look at three. What is put in the recordmode field.

We can see the help above and our previous observations. We can find that it is a description of the data status.
The first occurrence is "N". If the second occurrence is null, it indicates the latest data, and "X" indicates the previous data. What is the purpose of this description? When you delete a request and ODS returns the previous value, you can use this recordmode to know what the previous data is, so you can delete it resolutely. If you are busy, you may ask what other values mean. Sorry, let's talk about them later.

So far, you should have some knowledge about the change log table. Let's talk about another topic: delete change log data.

On the ODS Management page, you can see a "delete" in the menu environment.
Change log data sub-menu. You may think that the change log table can be deleted since it is replaced by a day. Not wrong? Yes. So what is going on? Why can I delete it? What are the limitations?

Why delete it? From the previous introduction, we can see that active data table has three records, while change log table has seven records, because it records the data change process and the latest data, it must be equal to or redundant.
The record row of the data table. Therefore, in terms of data storage, the size of its space cannot be ignored. In fact, we didn't use the change log table during the process of using ODS, so we thought: we should delete it, but we should be able to delete it.

It is useless because its usage process is transparent to us. If it is useless, it will not be useful and must be used. How to use it? If you have any questions, it means that my previous introduction is not very good.1. Its zeros are used for subsequent data updates. 2. Its change log can be used for data rollback after a request is deleted.

Of course, it can be deleted. The premise is: 1. I will never delete the request. 2. The zero-padding function has been completed.

The reason for the above conclusions is: 1.
If you want to delete the request, the data cannot be correctly rolled back, so the active data table is put with an incorrect value; 2.
When you import the data to another place using the change log, but it has actually been deleted by you, it is naturally wrong data.

Therefore, we need to delete the change log table with the following prerequisites: 1.. The request that has been deleted in the change log table will not be deleted later.
; 2. until the deletion point is reached, all data in other places to be imported from ODS has been exported. New requests will generate new change logs, which are independent of each other. At this time, you can boldly delete it.