In the Primavera PMDB tables most primary key columns are identified by that specific table _ID, example task_id on TASK, proj_id on PROJECT. This identifies this unique row. In the early versions of our STAR schema we had object_id's as well. W_PROJECT_D (Project Dimension) had project_object_id. W_ACTIVITY_D (Activity Dimension) had activity_object_id. Fact tables had a combination of all the associated object id's - project, task, etc. The object id's still exist but with the introduction of Multiple Datasources in P6 Reporting Database 3.0 an object_id was not unique enough. Take the Project Dimension for example, project_object_id has to be unique for each data source. But if you have a second data source that rule doesn't apply. You could have a project_object_id of 4527 in data source 1 and in data source 2. To make sure we never have this scenario occur row_wid's where added. The row_wid is a calculation of that specific object id * 100 and the data source id. If this project was from data source 2 the row_wid would be 452702. There is the possibility of having 100 data sources, however it is unlikely and not recommended. This row_wid is then used to help join other tables. The row_wid from the w_activity_d is referenced as activity_wid in other tables, similar to project_wid, eps_wid.
In the STAR schema is not the only place these wid's are used. They are also used in the RPD for joining between dimensions and facts. This way if in a multiple data source environment the wid's make sure the data being returned in OBI is also correct and unique to that data source. If doing manual manipulation of the RPD be aware that wid's may be the field you want to join on. Consider your environment, it's needs, and it's future - do you foresee an expansion with more than one data source - if so, plan ahead.