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

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

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

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

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

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

最近在做利用机器学习的能力提升数据库运维这样的产品。你这个问题其实挺好，我也在考虑思路。 首先把数据库的指标全部监控起来。然后对不同的系统相同的指标进行分类。也差不多就是说明这个系统的这个方面在整体数据中心里处于什么位置。同样这个味直接就是这个系统数据建模能力或者其他性能之类的体现。清楚系统的运行状况后，下一步就可以找到解决问题的方向，反推是应用改造还是资源升级等。