■来自社区交流，供参考
如何通过应用对数据库的设计和使用，去反推出业务在数据模型抽象方面的能力？
对于重业务的复杂的业务场景来说，业务模型抽象能力非常关键，另外数据模型的设计基本上关系到后续业务的弹性，那么从DB的来说，如何能够通过DB的使用情况，去反观业务在数据建模能力，给出一个打分或评价，大家有什么好的想法可以交流。
bryan软件架构设计师：首先，逆向思考这个问题。先从目的出发，为什么要对业务数据建模能力进行评价？评价的目的是为了什么？
一方面，如果一个系统能够满足各种业务需求，每个SQL语句响应时间很短，是不是就算作建模能力很好？一方面，从题干出发，考虑到系统的业务弹性，是不是说数据库的扩展能力呢？这个应该是在系统设计时需要考虑到的数据库容量规划。
然后，我们再正面回答这个问题。
在系统架构设计时，数据架构层面需要进行容量规划，部署架构层面需要考虑系统的扩展性等非功能性需求。一般而言，如果系统出现问题中担心的一些问题，可能是与前期架构设计不到位有一定关系。
那么，可不可以逆推出数据模型呢？数据架构的设计是按照业务模型、逻辑模型和物理模型三层设计实现的。作为DBA，看到的是最终的物理模型。如果逆推模型，可以通过数据表之间的关系（外键等），反推出一定的数据关联关系，并且有些数据库有类似的软件。
最后再考虑一个问题，有没有必要这样呢？
在我接受的一个烂系统中，我们是不去逆推建模能力，就是一个原则：有问题解决问题。如果数据模型设计不到位，最终会表现为业务处理速度慢。那么我们就分析哪些业务处理慢，再去分别他们的表结构，看看有没有合理的优化方式，从而进行改进。
那么建议是什么呢？一方面在项目设计初期做好数据架构规划设计，一方面在落地实施后哪里有问题解决哪里。
阳海IT顾问：感谢楼上分享。明白你说的，这样做的目的是为了逆向（从后朝前看）或者叫多角度去看业务模型设计，是一个由结果反推前期设计的想法，去发现存在的问题之后，去培训相应的业务。同意从一开始来做更好，是更应该做的。
amu商业智能工程师：我想题主问的是业务系统数据建模吧，那边建模的确是很关键的，尤其是集中化比较严重的核心业务系统，数据模型的创建水平直接影响到后续业务的拓展。
题主问的通过DB使用情况，去反观业务在数据建模能力这块，个人观点，是可以通过数据建模落在DB的模型之间的关系，以及业务对象抽象能力，结合业务发展方向，来审视具现的结果。
但是数据建模很大的影响，打分或者评价机制不太好评估，很多公司都是核心系统跑不动了，外挂的内容加不上了，才会反过头重新梳理如何更高效的进行建模。只通过DB展示出的内容，不如通过系统架构整体设计，去评价模型抽象的对象是否合理，各个表关系能否明细，易于拓展，并且对业务系统的改造影响最低。
非专业人士，只是有幸接触过此行业的人，了解过一些。
孔再华数据库运维工程师：最近在做利用机器学习的能力提升数据库运维这样的产品。你这个问题其实挺好，我也在考虑思路。首先把数据库的指标全部监控起来。然后对不同的系统相同的指标进行分类。也差不多就是说明这个系统的这个方面在整体数据中心里处于什么位置。同样这个味直接就是这个系统数据建模能力或者其他性能之类的体现。清楚系统的运行状况后，下一步就可以找到解决问题的方向，反推是应用改造还是资源升级等。
以上内容仅供参考，欢迎点击阅读原文，分享您的观点
长按