Peter,

Thanks much for responding to my query.  My primary interest in identifying the path complexity is related to software size estimation.  Given that most of the sizing methodologies indirectly measure the quantum of data movement across applications or their boundaries, ER diagrams should be a good source to provide a size measure. 

The quantum of entities, their attributes and path complexity were considered to be critical factors in arriving at a size estimate.   I came across a couple of papers discussing this topic; however, details of how they arrived at the path complexity was missing.

This is the context of my question.

Appreciate your thoughts on the topic.  To be more specific, the attempt is to measure the size of the software or the effort that is required to build it rather than data movement per se.  Would there be any relation between development effort and the database size as depicted in the ER diagram.  Your point is quite valid that an ER diagram is essentially static and need not necessarily give any clue on the actual movement of data.

Since estimation needs to be predictive, something that can be produced at the conceptualization phase of a project (say, with a conceptual diagram, or logical diagram) will have obvious value.  Frequency of use of particular tables or fields  would be available from Use cases / requirement documents; they only come slightly later in the game.

I had come across a couple of papers in this line.  Let me try to retrieve them.

Once again, thank you so much for a very thought provoking discussion.

Graph complexity hasn't shown to be a good predictor of development effort. For example the McCabe Cylomatic number in one such example. In a number of studies, it has not predicated development effort, but does predict the time to develop test cases for path coverage. Complexity is an aggravating factor to development time, but is not necessarily a primary factor.

What you might want to investigate are the various point techniques, such as function points, feature points and object points. They use the number of data stores to calculate an overall size and depending on the architecture (i.e. CRED) it is possible to establish the number of interface necessary. These points convert into lines of code which is the only size measure that is widely known to predict development effort.

Formal models are good for estimating the development effort, but the model is completed late in the process (waterfall, scrum). Generally, management wants an effort estimate that included the modeling or design process. In essence, the question is what will it cost to provide the require facilities, This is why the point techniques are favored by many developers.