Reverse engineering is a broad term, but in this scenario it refers to the process of reading the structure of database tables and their relationships, and defining the necessary GeneXus Objects (data model) to represent the schema.
GeneXus' basic secret is the URA attribute naming convention. Most Databases do not use this attribute naming convention. The key objective of this process is to convert your Database schema to a URA based schema. Reverse engineering a non-URA major input affects the referential integrity constraints defined in the schema. Although you can use this tool even if you have not defined the database referential integrity, it is better to use it when the referential integrity is defined.
The DB Reverse Engineering tool does not change your Database in any way. It just reads the table structures and their relationships. It does not even attempt to read table data.
At the end of the DB Reverse engineering process you will have a GeneXus Knowledge Base pointing to your database and you will be able to access or update it.
A GeneXus Transaction is created for each database table that has the same attributes. Based on the constraints defined in the tables, the actual "GeneXus name" attribute may be different from the original. DBRET could change the internal attribute name to enforce the URA concept. Let us see some examples.
Example 1
Consider the following four tables and their referential integrity constraints. As you can see the same attribute name is used for all of the primary keys of the tables, and some of its secondary attributes. The following constraints were also defined in the database (shown with the arrows):
Invoice.Client --> Customer.Code
InvoiceLine.Code --> Invoice.Code
InvoiceLine.Prod --> Product.Code
After DBRET processes the schema, the following GeneXus Transaction and Tables are created:
As you can see, some attribute names have changed. Now you don't only have a "Name" attribute, you have, for example, a "ProductName", which gives you context information and will enable you to program new objects without worrying about how to join tables.
Example 2
There are some cases in which GeneXus cannot use the same attribute name to represent the same thing, but still needs to maintain the relationship. For example, in specializations, self-relations, or when it has two or more foreign keys for the same table. In these cases, a Subtype Group object will be created.
The following example shows a specialization diagram for an external Database, where all the primary keys were defined with the same name.
DBRET will define the internal tables as follows:
The following subtype groups will be also defined to maintain the relationship between tables:
SALES GROUP
SalesEmployee subtype of Employee
SUPPORT GROUP
SupportEmployee subtype of Employee
The third GeneXus object created by the DBRET during this process is the Data View This object contains all the internal-table-to-external-table mapping information. As we saw above, some internal attribute names have changed. Data Views define, among other things, the mapping between Genexus and your database schema. The internal names are used in GeneXus objects, but the generated programs will use the external ones.
See also: Database Reverse Engineering Wizard