Integration with databases

The database structure of "Force-Field" allows for quick integration with most applications.

"Force-Field" operates with internal presentation of protected objects; a special structure the component works with is formed on the basis of application database.

To integrate an application database with the "Force-Field", it is necessary to create two views - FF_Object ? FF_Person. First view maps logical application objects into the "Force-Field" objects hierarchy, second allows the component to access to the existing users repository of an application.

Database of an application can contain a number of tables that represent logical objects; each of the tables has integer-valued primary key. FF_Object is formed on the basis of database structure and contains the following fields: object_id, owner, class, parent. Fields are used by "Force-Field" to create the internal presentation of an application objects.

An application database can use through numbering of objects, in that case the integration is obvious to fulfill. It's also possible that an application database doesn't use through numbering of objects. If each object doesn't have a unique identifier (ID) within the system, the identifier can be generated. There are some methods to solve this problem. Let's have a look at one of them.

To avoid the repetition of identifiers during the consolidation of objects from different tables within FF_Object view we can shift original identifiers for one digit. Let's assign each type of logical objects with one-digit unique number. If a database table is considered as a type of objects, then each record in this table is an object that should be put into the FF_Object view. We shift the identifiers of objects (i.e. table records): the rightmost digit of the generated identifier will be the type number we've assigned and the rest -the original identifier that a record has in the database table of an application.

For example, an application uses a table "Manufacturers" to store information about goods. There are two other tables connected with the first one - "Monitors" and "Printers".

Let us suppose that the type "Manufacturer" has identifier numbered as 1. Objects from "Manufacturers" table will have in the FF_Objects the following IDs: 11, 21, 31 and so on. The last part of identifier points to the object type and the first - to the identifiers of the records from the table "Manufacturers".

Objects from table "Printers" in FF_Object view are objects of type numbered as 2. In FF_Object they'll have the following IDs: 12, 22, 32, 42 and so on.

Objects from table "Monitors" in FF_Object view are objects of type numbered as 3. In FF_Object they'll have the following IDs: 13, 23, 33, 43 and so on.

Finally, we can assign 1 as the identifier (ID) of the root object.

This method to generate identifiers for FF_Object view helps to avoid possible repetitions of identifiers.

To build the internal "Force-Field" presentation of objects for a database that uses identifiers of another type (not integer-valued) you'll need additional transformations. E.g. interim table should be created.