Reviewing the lockup process, version 4.6.6.6


In the process of reading the Brand dimension from Embrand, the narrator utilized two instances of the lockup transformation: one using the dimension lockup and the other, the fact lockup. Let's revisit the lockup process and understand how the transformation occurred.


Firstly, let's discuss the Brand lockup. At the time of processing this transformation, the tables were in the following state: the transformation contained only brand and category descriptors, and the lockup table, which is the destination table, was empty, as shown on the slide. The process is a dimension lockup process.


With the lockup criterion being the Brand field from the source, the search criterion the Desk Brand field from the destination, and the Code Brand field to determine the sequential code that will serve as the identifier we want to determine. When it reads the first row, "Frescor de Verão," it won't find it in the lockup table as it's empty. Since there are no elements in the table, the value to be determined as the identifier for this brand will be 1. The same will apply to all other brands, creating sequential coding.


Moving on to the second lockup. The state of the tables involved in this new lockup is as follows, as shown on the slide. The process is a fact lockup process, with the lockup criterion being the Category field from the source and the search criterion the Desk Category field from the destination.


However, the objective now is not to determine new codes for the entity but to retrieve the existing codes. And if it doesn't find this code, it defaults to the value 1. When reading the first row, "MATCH," the process will search for this same descriptor in the lockup table. Upon finding it, it will determine its code.


Therefore, this code is recorded in the table representing the result of the transformation. By performing this process for all rows, we will have the category codes in the transformation of the brand table. Thank you, and see you in the next video.