Maybe the first question is: "Why would you need an index that would involve two distinct tables?"
If there was such a type of index, the most correct to affirm is that it would be a type of "Cartesian product". How could you normalize the relationship between two columns of distinct tables? How would you like that "record 1" of a table would need to be associated with the "registration 20012" of the other table?
An index will always be associated with a table and usually aims to streamline queries or construct data integrity rules (PK / AK). If by chance I need to make jollys of two distinct tables, I can choose to create distinct indexes in these two tables, involving the Join filters (Clause Were).
I do not have a practical example here, but if I have two tables that present relationships "too much for many", I can create an intermediate entity (relationship table).
Example:
In the example above, the table "A x b" would be composed only by join columns between "A" and "B", and you could create a "Composite PK" (Primary Key) or an "AK Compound" index with these columns.
I hope forists can give a better explanation for your doubt,
Hugs,
Thanks for the tip but I tried to create the Bitmap index and Oracle raised the error ora-25954 saying that it should have a primary key constraint.
In my situation I have a table of (Employees) 1 for N (courses), until then I can create a constraint in the Employees table but in the Table No.
In the current scenario is still possible to create the bitmap index?
Heraldo, for this case unfortunately it is necessary to have a relationship between the tables. This type of index is widely used in BDS OLAP queries that consult clothing tables and dimensions, scenarios where there is the referential integrity between the tables.