OpenMiner已经成为了sourceforge的approval项目。与此同时，我们也开始紧张地对OpenMiner进行了一系列的外科手术。我现在做的主要是服务器部分的裁剪，尽量把OpenMiner的核心做得更加简单，更加具有扩展性。
OpenMiner已经成为了sourceforge的approval项目。与此同时，我们也开始紧张地对OpenMiner进行了一系列的外科手术。我现在做的主要是服务器部分的裁剪，尽量把OpenMiner的核心做得更加简单，更加具有扩展性。而OpenMiner现在还没有可视化的客户端，另外一个同学grand现在也开始加紧赶制OpenMiner的客户端，我们的客户端打算仿造Yale。
首先的第一个手术就是减掉阑尾。 之前在给教务处做决策系统的时候，为了赶进度，OpenMiner过于依赖了Oracle数据库，各种数据集的提取，以及挖掘模型的存取，都是基于Oracle的JDBC来访问的。而Oracle的JDBC特别是在处理BLOB数据块的时候，又和标准的JDBC不兼容，于是搞得代码很不具备通用性。现在的OpenMiner，不仅是需要对ORACLE的很好支持，同时还要能够对各个方面的数据集进行很好的访问，当然，训练数据集都是只读，也就是OLAP。作为一个数据分析，我希望设计处理的服务程序不仅能够从数据库中提取数据，还希望能够从各种文件格式(excel, xml,等)，以及远程的Socket输入流来获取训练数据集。减掉了旧的Oracle处理模块后，需要新增加的就是一个比较齐全的输入数据抽象层了。采用设计模式中的抽象工厂Abstract Factory的方式来实现。这样，对于数据挖掘的算法模块来说，就只有一个InputDataSet输入数据集的接口，训练数据就只能从这里面来提取，根本不用去理会这个InputDataSet是一个什么样的数据来源和怎么样创建的。于是乎，文件数据，数据库数据，Socket流输入数据，就能很好地统一到InputDataSet接口下了。
其次，关于使用挖掘模型的接口函数，统统从Miner类删除。因为如何使用一个挖掘完成的模型，是根据应用程序Application来决定的。如果OpenMiner来做，并不见得做得能用，而且，使用一个模型的方法千变万化，OpenMiner做起来也麻烦，于是，最好的办法就是，不做，统统删除！
最后，我考虑将挖掘模型的存储访问管理，放在客户端来进行。原因很简单，OpenMiner就只做Data Mining的工作，不做Data Mining以外的任何工作。这里所谓的客户端，并不一定就是用户实用的客户端，也可能是应用系统，只是从OpenMiner服务提供者来说的客户端的意思。如何管理挖掘模型Model这个问题，本身并不能轻率，因为现实企业应用系统中，可能挖掘模型数量成百上千，如此庞大的挖掘结果模型，一般的文件系统并不见得高效，而应该放在数据库的，针对各种数据库的访问，那么就成了一个问题。同时，挖掘模型也可能存在安全性的问题。要让OpenMiner去这样复杂的一项工作，很难做得好。既然做不好，最好的办法就是，不做，统统删除。
做了这些过后，OpenMiner的核心服务器的手术基本上可以算完成了。剩下的就是客户端的事情了。我们现在的这个客户端功能很大，把以前本该是服务器做的模型管理的工作都移交到了客户端来做，于是grand现在也忙起来。关于客户端的开发，我推荐使用NetBeans 5.5RC1来开发。因为Eclipse的VE插件做得太老火了，经常出问题，而且又慢又兼容性也不好（3.1和3.2的VE都不兼容）。而NetBeans本身就自带了可视化的界面开发功能，速度和稳定性都比Eclipse那种外部插件的好。虽然Eclipse一度成为IDE的典范，但是SUN的新秀NetBeans也有它不错的有点。随便说一下，NetBeans也是免费开源的，可以随便下载。
京公网安备 11010802021500号