如何通过应用对数据库的设计和使用，去反推出业务在数据模型抽象方面的能力？

首先，逆向思考这个问题。先从目的出发，为什么要对业务数据建模能力进行评价？评价的目的是为了什么？
一方面，如果一个系统能够满足各种业务需求，每个SQL语句响应时间很短，是不是就算作建模能力很好？一方面，从题干出发，考虑到系统的业务弹性，是不是说数据库的扩展能力呢？这个应该是在系统设计时需要考虑到的数据库容量规划。

然后，我们再正面回答这个问题
在系统架构设计时，数据架构层面需要进行容量规划，部署架构层面需要考虑系统的扩展性等非功能性需求。一般而言，如果系统出现问题中担心的一些问题，可能是与前期架构设计不到位有一定关系。

那么，可不可以逆推出数据模型呢？数据架构的设计是按照业务模型、逻辑模型和物理模型三层设计实现的。作为DBA，看到的是最终的物理模型。如果逆推模型，可以通过数据表之间的关系（外键等），反推出一定的数据关联关系，并且有些数据库有类似的软件。

最后再考虑一个问题，有没有必要这样呢？
在我接受的一个烂系统中，我们是不去逆推建模能力，就是一个原则：有问题解决问题。如果数据模型设计不到位，最终会表现为业务处理速度慢。那么我们就分析哪些业务处理慢，再去分别他们的表结构，看看有没有合理的优化方式，从而进行改进。

那么建议是什么呢？一方面在项目设计初期做好数据架构规划设计，一方面在落地实施后哪里有问题解决哪里。