Before I kick this one off, please remember that these measures can only be taken into consideration when the full scope of the database model and its implementation are known. 

The Abstraction Indicators try to measure the databases capacity to cope with change and the "profile" of the database to calling applications.  Abstraction in this context means to hide internal schema changes from users.

These indicators are relevant to the entire database only and must be taken with a huge grain of salt.

There are 2 components

1. View Abstraction
   • I won't go into the all the reasons why views are so good, but simple state that the power of a view to abstract the underlying model is second to none.
   • This indicator considers the most basic relationship possible between 2 tables that a view could practically be considered for.  (PK-FK)
2. Procedure Abstraction
   • Stored procedures (when used with a security model) effectively create an API for calling applications/users.
   • Based on the principle of CRUD, this indicator assumes that 4 procedures are needed to abstract a table from a user.

Interpreting the results

• View Abstraction
  • A score over 1.00 usually indicates a well thought out implementation. 
  • Scores below 0.10 need  to be investigated.
• Procedure Abstraction
  • A score over 1.00 is assumed to have a tight API defined.  This assumes that each table has a CRUD equivalent.
  • Any score under 0.25 usually means that the calling application is doing most of the SQL writing.

Select ProcCount/4.00/TableCount as ProcedureAbstraction
    , ViewCount/0.5/TableCount as ViewAbstraction
from
(
Select count(*) as ProcCount
    , (Select count(*) from INFORMATION_SCHEMA.TABLES where TABLE_TYPE = 'BASE TABLE') as TableCount
    , (Select count(*) from INFORMATION_SCHEMA.VIEWS ) as ViewCount
from INFORMATION_SCHEMA.ROUTINES
where ROUTINE_TYPE = 'PROCEDURE' AND LEFT(ROUTINE_NAME, 2) != 'dt'
) as X