做数据挖掘、分析，从数据推测出原来开发人员表的设计思路，从而知道数据的来源与去向

根据用户界面，把软件的功能，功能和模型的关系搞搞清楚就可以了。

如何实现不重要，那些你应该去看编程的书籍。

引用 1 楼 hdhai9451 的回复:

做数据挖掘、分析，从数据推测出原来开发人员表的设计思路，从而知道数据的来源与去向

引用 楼主 abcd880129 的回复:

没有源码，但是有数据库的产品，如何研究学习。比如如何跟踪某个动作，。。。

不知道你所谓的“产品”有多大，多重要。但是一般来说，通常只有非常悲催的、在一个小办公室里使用的简单OA才会如此。

特别是复杂的网络软件，其后台服务端做的是业务操作，而不仅仅局限在“增删改查”。

例如一个最简单的下载站点上的服务端的“查询下载资源”服务，服务端可能需要在全网上查询相同编号的资源是否存在，如果存在则对比客户端跟服务器端的md5签名是否一致，如果不一致则根据客户端请求参数的不同、或者删除资源或者返回特定信息给客户端。这样的功能还算值点钱，这样的功能需要有几十个。而什么“增删改查”并不值钱。

所以分析一个产品，要看懂真正部署到大环境之后产生技术壁垒的架构。而不是什么“增删改查”。

你的客户端访问下载站，可能只要写一行

new WebClient().DownloadFile("http://www.abc.com/site1/download.ashx?name=akdfak&md5=4cf79273333ab82838243", targetPath);

就行了，你根本不关心服务器端价值几千万的硬软件投资，根本不关心有多少系统在服务。

分析设计产品，进行研究学习，是为了提高你设计出来的东西的价值。因此你有所谓“研究和学习”某些动作，其实是这种动作设计，而不是那种数据库查询语句。

所有可能留下痕迹的动作，你都可以“轻飘飘地”说是“增删改查”。但是我们因此就看到有些人好几十年也都是再重复千篇一律的基本理论，而一旦做产品就全都成了千篇一律毫无创意界面完全一样的一堆OA办公软件功能模块了。

说数据库表结构是个很想“省事”的做法。可惜这往往意味着此人无法对一些稍微复杂一点的实用软件系统进行逆向工程。