I'm assuming DEREF is short for "dereference". In the context of the SMS, I'd surmise dereferencing treats the object UIDs (or other attributes) as a pointer to the full underlying object properties. As stated on page 25 of the CCSM guide, the table dleobjectderef_data contains object attributes that are accessible by "legacy" management processes such as fwm, as that object data was originally stored in the proprietary CPMI format prior to R80 (objects_5_0.C?). The other postgres table CPNetworkObject_data is for the "new" R80+ processes like cpm, and those two tables are kept synchronized in the database. So I'd guess the dleobjectderef_data table is essentially backwards compatibility for the older process elements of the SMS implementation, and helped avoid the massive effort that would have been required to rewrite the legacy processes like fwm to utilize the new database structure for objects via CPNetworkObject_data.
Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com