2007年8月28日
#
如何在ERP系统基础上拓展SRM系统
上网时间:2006年12月01日
作者：:韩岩杰
在多变的市场环境中，上下游信息协同所处的地位尤为重要，而要进行协同，就不能局限在企业内部，在这方面ERP系统就显得有些力不从心了。为了解决上下游信息协同问题，SRM系统应运而生。SRM系统要建立在已经实施ERP系统的基础上。
协同采购 Guru e-Procurement
实现您与供应商的高效协同： 与企业内部信息系统紧密结合，灵活支持JIT、PO采购、Consignment/VMI等多种采购模式。通过电子化交互手段，提高采购人员作业效率、降低企业的采购运作成本；通过任务导航、智能示警及送/收货看板等工具，提高双方协作效率；利用信息的实时分享，实现供应与生产的高度配合。有效建立与供应商紧密协同的伙伴关系。
采购寻源 Guru e-Sourcing
构建您的战略采购平台： 基于企业的总体战略，利用电子化手段，全球寻源、科学评估、充分认证、网上竞标，以一整套规范有效的供应商开发体系 帮助企业建立战略性供应体系。
供应商绩效评估 Guru e-Supplier Rating
优化您的供应结构： 系统建立了科学完善的供应商绩效评估体系，运用绩效评分卡对供应商绩效进行全面评估，实现客观定量评价，并可结合人工灵活评判数据，形成综合评价分析。评估结果能进行多纬度分析，帮助企业制订供应商发展策略。
明基逐鹿Guru SRM（供应商关系管理）系统是一套完整的供应链采购端解决方案。Guru SRM为企业构建全面的供应商管理平台，从供应寻源，到采购协同，到供应优化，提供了一套科学、高效的全面供应商关系管理的思路，让供应商同企业无缝集成，针对生产、市场的变化，敏捷应对、随需而动。
Guru SRM整体解决方案分为三部分：
软件公司SAP的主管预言，一波整并浪潮正席卷信息科技（IT）业，一旦顾客缩减供应商数目，许多开放源代码商用软件公司可能被抛在市场后头。
SAP销售专有的企业资源规划软件，用来记录企业财务并管理与客户的往来关系。这家德国软件公司面临OpenMFG、SugarCRM、Compiere等公司的竞争。
不过，SAP营销执行副总裁Peter Graf在开源商业会议中表示，这些竞争对手尚未形成气候，恐怕难成大事。他指出，每当市场发生巨大的变革，例如顾客把电脑改装得适用于互联网，用户会比较信赖自己熟悉的公司。
“市场整并时，人们会把资金投入最多钱押注的那一方，”Graf说：“哪些开源技术的成熟度够，足以挺得住即将来袭的这股滔天巨浪Linux--肯定是。Eclipse应该是。 Mozilla可能是。”
Graf说：“我们认为，开源商业应用软件发展还不成熟，来不及应对这股巨大的整并潮流。”
开源软件公司运用协作、分享的程序设计方法，逐渐对专有软件公司构成竞争压力，尽管Graf和其他专有软件公司的主管淡化开源公司的竞争威胁，但态度上却已转变。
例如，IBM就买下一家称为Gluecode的开源Java应用程序服务器公司，数据库巨人甲骨文公司(Oracle)也考虑收购开源公司MySQL。
SugarCRM首席执行官John Roberts则对Graf的说法不以为然。他说，今天，SugarCRM的技术已臻成熟，供大型企业客户使用绰绰有余。
Roberts接受访问时表示：“我们乐得和他们竞争。随时奉陪。”他说，已有客户舍弃SAP、改用SugarCRM的产品，Avid Technology公司就是一例。
Compiere首席执行官Jorg Janke也表示，开源软件够成熟，如Compiere的软件就获得一家门市多达2,000家的法国美容产品制造商采用。
不过，Janke不讳言，一些对开源商用软件的批评言之成理。他说：“太多人以为，开放源代码是推出商业应用软件的捷径，试图快速取得创投公司的资助。”
他指出，SAP也采用多种开源程序，包括Eclipse程序设计工具，以及Java应用程序服务器软件元件，例如Apache的Struts和JBoss的Hibernate，足见许多开源软件运用广泛，足以持续发挥其影响力。
德国商业软件公司SAP在最近宣布，今后该公司的软件产品，如人力资源管理软件，将可以更方便地在微软操作系统上运行。这标志着两大软件巨头之间的爱恨纠葛又掀开了新的一页。
通过“适应性计算”，SAP的软件可以运行在更多不同种类的硬件和软件系统之上，其中包括微软数据库和操作系统。以往那些只能在大型机上运行的软件将可以在相对廉价的小型机上运行，从而降低成本。
以前SAP的软件只能运行在Unix或Linux操作系统上，此次兼容微软操作系统将为SAP赢得更多中小企业客户，因为这些公司的软件大部分都是基于微软系统的。
SAP渠道市场部副总裁Ori Inbar表示：“以前我们主要关注Unix和Linux运行环境，然而现在有越来越多的用户使用微软系统，我们必须满足他们的需求。”
分析家认为，此举可以大幅降低SAP软件的运行成本。以SAP的客户高露洁公司为例，通过采用适应性计算应用方案，它节省了70%的硬件开支。
适应性计算主要是通过NetWeaver技术来实现的，该技术使得用户可以将不同平台和数据库的处理过程整合在一起。
SAP兼容微软系统的做法深得用户欢迎，因为目前有50%的SAP用户使用微软SQL Server数据库和Windows系统，他们迫切希望加强不同平台间的互操作性。
Inbar称：“这是我们加强与微软系统互操作性的重要一步。”
在去年4月，SAP已经与微软达成合作协议，通过Mendocino技术将前台的微软个人软件与后端的SAP商业软件进行整合。例如，用户可以将微软Office软件与SAP应用程序结合，从而节省中间的开发环节。
SAP高级官员Shai Agassi在德国汉诺威CeBIT展上表示，该公司希望借助微软系统的垄断地位来开拓更大的市场。他认为在不久的未来，微软Office软件与SAP软件的互操作将变得更方便。
他称：“兼容微软系统对于我们来说非常重要，毕竟Office的用户数量是SAP的四倍。不过SAP软件可以完成许多Office无法胜任的工作。”
尽管微软和SAP在应用软件市场处于激烈的竞争状态，不过他们在高端市场却展开了亲密无间的合作。
EA咨询公司分析师Josh Greenbaum称，通过与微软合作，SAP扩大了自己的用户群基础。这种以操作系统为后台，以Mendocino应用为前端的合作方式对于双方都有利。
继去年底SAP在韩国成立射频识别标签（RFID）研发中心，拓展RFID技术发商务软件开发之后。近日，SAP携手Sybase成立全球联合联盟，整合两家公司的RFID中间件。
据悉，双方的合作层面主要围绕Sybase的射频中间件。
Sybase RFID Anywhere 2.0
安全中间件通过了SAP认证，可与SAP自动识别基层设施中间件协同工作，SAP的自动识别基层设施的功能是将RFID标签数据整合进入企业应用程序。Sybase也成为第一家可将RFID
软件与SAP集成的中间件供应商。
据市场调研机构IDTechEx研究表明，包括系统和服务在内的电子标签（RFID）市场规模将从2006年的27亿美元狂涨到2010年的123亿美元，到2016年市场规模将可能扩展到262亿美元。
在此之前，SAP还曾与英特尔合作共同开发RFID数据直接导入系统。SAP联手英特尔为其RFID设备提供无缝集成方案，也为读卡机提供更多的智能特性。加之Sybase软件的助阵，SAP在RFID领域的功能堪称完备。
自Sybase收购生产远程管理软件公司Xcellenet，并使用其技术开发RFID中间件产品后，Sybase开始大量生产RFID 电子数据采集设备及软件，包括以为RFID读取器和条形码扫描器以及打印机提供一个接口和系统管理工具。该软件还可以自动将RFID数据载入SQL数据库，并提供专门的RFID数据库模型以存储其他与业务相关数据。
无独有偶，SAP的竞争对手Oracle，也曾与Sybase联手合作，把RFID整合到传统的企业数据之中。在完成整套RFID软件包的研发之后，Sybase一改传统数据库厂商形象，成为RFID领域炙手可热的企业，SAP、Oracle等商业软件巨头更是频频向该公司抛出橄榄枝。
Sybase公司RFID主管Chris Foley对此表示，整套RFID软件包可以将标签阅读器收集的数据集成到公司的IT系统中以供分析。这一产品的目标是那些处于混合结构环境的公司，其中包括对将RFID数据整合入SAP、Oracle和其他ERP系统提供支持。
SAP公司CEO在本周三表示，目前信息技术领域掀起了一股合并狂潮，而这股狂潮必将把那些规模较小的开放资源运营商扫地出门。
美联社报道，SAP公司的主营业务集中在企业资源管理领域，并且涵盖客户关系管理市场，然而随着开放资源软件制造商的兴起，例如OpenMFG、SugarCRM以及Compiere等，SAP遇到了前所未有的压力。然而，在开放资源商务大会上，SAP公司公司副总裁表示，这些开放资源运营商目前还不够成熟，因此撼动SAP的地位仍然只能是纸上谈兵而已。“我们相信，在这股整合狂潮的席卷下，开放资源软件运营商根本挺不到进入成熟期。”副总裁先生克力夫如是说。
实际上，克力夫已经不是第一位对开放资源泼冷水的私有软件制造商领导了，然而分析家表示，这些私有软件制造商的豪言壮语，很大程度上是在为自己壮胆，私下里多家表示不在乎开放资源的软件制造商已经悄悄的开启了开源计划，例如蓝色巨人IBMN购买了开放资源Java应用程序服务公司Gluecode，与此同时数据库软件巨头甲骨文也正在酝酿对于开源数据库运营商MySQL的收购。不过克力夫先生仍然在大会上坚持了自己的观点：“哪家开放资源软件运营商可以在这股收购合并狂潮中幸存下来？Linux毫无疑问是其中之一，火狐浏览器Mozilla也许也可以，不过其他公司的可能性微乎其微。”
商务软件制造商SAP公司首席执行官对印度越来越高的员工工资表示不安，并计划寻求转移到其他费用较低的地区。
印度是全球最大的软件开发外包服务市场之一，越来越高的员工成本促使商务软件制造商SAP公司已经开始考虑到低成本地区寻求技术熟练的软件程序师。
当地时间本周一，德语版《金融时报》公布了商务软件制造商SAP公司首席执行官Henning Kagermann在一次接见时说的话：“印度员工的费用正在慢慢的增长，我们决定在那里只雇用一定数量的员工，我们已经开始考虑其他费用较低的地方。”SAP公司发言人 弗兰克-哈特曼证实了首席执行官的声明。
首席执行官尖锐的指出，印度员工的工资正在上升，雇用员工的成本在增长。哈特曼说：“在软件行业，员工的成本是一个关键的因素。”
在印度软件开发外包服务市场，在与高科技巨头 IBM公司、微软公司和印度当地IT 公司的竞争中，较高的雇用员工成本使SAP公司面临更大的压力。据首席执行官表示，SAP公司可能将向中国和东欧扩展。
目前SAP公司在中国的软件开发力量非常有限。他说：“尽管中国的知识产权保护力度较低，但并不影响我们在中国进行更多的软件开发。”首席执行官表示，目前SAP公司在中国大约有1000名员工，主要进行 销售和营销运作。
东欧是德国软件卖主SAP公司首席执行官感兴趣的另一个软件外包开发的场所。尽管东欧的交易量不高，但那里的员工成本也较低。
现在，SAP终于宣布推出测试性的按需CRM产品，并开始涉足竞争对手占主导地位的市场。未来，按需市场前景如何？谁会是最后的赢家？
7年前，当Marc Benioff创立Salesforce.com时，就立志要终结软件销售模式。他预测，迟早绝大多数的企业会把管理自己的服务器或是软件应用的任务交给象Salesforce.com一样的公司。近年来，Salesforce.com的发展令华尔街吃惊，但是业内大规模地向他预测的方向发展的速度似乎并不是很快。
现在，这种情况也许会发生改变。今年2月2日，SAP公司惊人地宣布推出其第一款按需服务，这种服务整合了面向中小型企业的软件管理、服务和市场行销等。与Salesforce.com一样，SAP的CRM服务以订购模式出售，SAP的按需服务为每月每位用户为75美元，而Salesforce.com的则为65美元每人。
SAP称，这种按需服务是一种新的应用“混合体”，旨在在客户的电脑上实现运作，SAP公司负责产品和技术部门的总裁沙·阿加西称：“这不是软件时代的终结，这是软件安装的另一种形态。”
分析师称赞，SAP的战略应对挑战的一种务实表现。据市场研究机构IDC的分析，2005年按需销售仅占全球90亿美元的CRM市场的6%，在未来5年之内，其占有率会提升到25%，该组织的分析师Mary Wardley称：“这种情况对于SAP来说是一种局限性”。
SAP对自己的举措也很低调，称绝大多数和大型企业购买CRM服务会从临时性向提前预定转型，SAP公司负责产品解决方案的执行副总裁Peter Graf称：“绝大多数的客户在整合其它程序时遭到了灵活性不足的问题”。
通过这种不温不火的举措，SAP一方面向按需销售市场进军，另一方面也没有大张旗鼓，瑞士信贷第一波士顿的分析师Jason Maynard称：“SAP认为，按需服务只是局部范围的业务，这是一种聪明的做法。如果我是SAP，我会把按需销售当做业内一种主要的潮流进行推广。”
这种新的服务是否会在市场上取得胜利？分析师警告称，SAP的这种测试性举措会使其按需销售前景大打折扣。但SAP希望，一些使用传统的财务、生产计划和供应链管理的企业将会向CRM按需服务过渡。比如，DuPont称，公司将在使用Salesforce.com服务的部门继续推广这种服务，同时在其它的部门购买SAP的CRM按需服务。未来，公司将在CRM应用方面实现标准化。该公司的市场行销主管 Mike Michlovich称，在公司的后台SAP软件包中会整合客户和订购数据，这意味着SAP是优先选择。
但Benioff指出：“SAP的举措是一种防御性的举动，我们正在渗透他的客户基地，客户意识到他们没有从SAP那儿得到想要的东西。”目前，Salesforce.com有1.87万客户，约35.1万个人用户。有50多个企业客户至少有600名用户，而大量的企业客户用户人数则达到了数千人。
他意识到，在拥有SAP软件的企业中Salesforce.com的服务是很容易受到攻击的，这其中包括德国银行、德国邮电和沃达丰客户。但他预测：“如果一开始因为政治的原因我们推动失去一些客户，但最终我们还是会获胜。”
随着SAP与Salesforce.com竞争的加剧，他们最激烈的较量将是与甲骨文的对阵。2月1日，甲骨文完成了55.8亿美元收购Siebel公司的任务，其取代SAP成为全球CRM传统软件市场的第一供应商。
此前，甲骨文同时推出了传统和按需CRM产品。现在，通过整合Siebel公司，甲骨文会在传统和按需CRM产品市场与SAP的竞争中处于上风，部分原因是Siebel未来不确定因素得到了解决，客户恢复了对再次购买Siebel的产品的信心。甲骨文公司负责按需业务的执行副总裁Juergen Rottler称，甲骨文与SAP相比，在推动按需服务产品方面会更具竞争力，“我认为，按需服务是我们业务的未来。”
随着SAP进入CRM按需产品市场，业内未来多了一丝光明，阿加西称：“我不知道未来5-10年会是什么样子，但与SAP只出售传统的软件产品的时代相比，公司未来肯定更具活力。”
作为全球最大的两家商业管理软件提供商，SAP与Oracle在诸多领域有着业务重合，双方多次因为在应用管理软件的座次大打口水战。在完成对Siebel Systems收购后，Oracle毫无争议地坐上了客户关系管理软件(CRM)老大的位置，一向不服输的SAP也心服口服。不过，这家全球第三大独立软件供应商迅速拉来IBM坐靠山，掀起了自己的反击战。
Oracle+Siebel
以数据库起家的Oracle的业务已经涵盖底层数据库、中间应用平台以及应用软件3个层面。众所周知，Oracle在数据库和中间件实力都不容小觑，相对薄弱的是应用软件，Oracle期望通过并购迅速增强其在应用软件方面的强力。Oracle的CEO Larry Ellison深谙，如果不能击败竞争对手，那么最好的办法就是收购。
成功吞掉仁科(Peoplesot)后，Oracle的胃口显然更好，从2005年9月宣布收购Siebel Systems到顺利吃掉，Oracle只用了短短四个月时间。
2006年2月2日，伴随着Siebel Systems公司股东投下的赞成票，Oracle完成了对客户应用解决方案提供商Siebel Systems的收购，一举成为全球最大的客户关系管理软件提供商，并不轻松的把老对手SAP甩在了身后。
收购伊始，Siebel Systems公司CEO George T Shaheen 说，Siebel针对此次收购访问了一些客户，客户认为与甲骨文的结合有好处。尽管以前两家曾经是竞争对手，但两者互补性很强，甲骨文有数据库、中间件和其他应用软件等产品，将会给客户提供更好的支持。
而Larry Ellison更是不止一次承诺，将照顾原Siebel客户，提供更完善的服务。对Siebel的合作伙伴来说，甲骨文的全球布局和丰富的产品线，将有助于扩展投资的领域并把投资的效果发挥得更有效。
SAP+IBM
两年前，SAP一度声言要取代Siebel成为CRM业内新的王者。令SAP投资者郁闷的是，SAP不但没有超越Siebel，反而被Oracle挤上了CRM头名的宝座。
并购Siebel Systems是软件巨人Oracle历史上第七宗大规模的并购。去年刚以103亿美元并购仁科，是收购狂人 Larry Ellison 打造“大而全”的公司的理念的产物。Oracle一系列的收购也招致了众竞争对手的泄愤，其中包括言辞激烈的SAP以及不露声色的IBM。
近日，SAP携手其重量级合作伙伴IBM推出了CRM托管服务。事实上，SAP与IBM间的合作早已初露端倪。自从甲骨文去年收购仁科之后，彼此的合作关系似乎又加深了一层。双方都心照不宣一点，敌人的敌人应该是自己的朋友。
此前IBM曾为SAP优化版本DB2提供支持，而在最新开辟的CRM托管服务方面，IBM已经与Siebel Systems建立合作关系，但当Oracle最终完成对Siebel Systems收购之后，“SAP+IBM”这一联盟随即呼之欲出。
伴随CRM托管服务的推出，SAP新添了一系列“渠道友好”型强兼容销售新政，继续与Oracle争夺客户。SAP的CEO卡格曼表示，公司更加关注现有业务发展而不是通过收购。这句话无疑是含沙射影说给Larry Ellison听，Oracle在合并仁科不久后，就陷入了同SAP的客户拉拢战。SAP趁机推出了“安全过渡计划”，其优厚条件吸引不少原仁科用户投入自己的怀抱。
SAP此次必然打算故技重施，在卡格曼看来，SAP的业绩已经再次证明现有业务发展的自然增长规律，无论对客户、合作伙伴还是股东都有益处。CRM托管服务，估计正是其所谓“现有业务的发展”。
Kagermann担任SAP首席执行官六年，担任执行董事更长达15年，目睹软件业授权模式的转变、软件供应系统的调整、企业用户日益接纳消费者导向的应用程序，以及大型应用软件企业的整并趋势。
问：Salesforce.com的成功，让人人开始谈论随选(on-demand)应用程序。你怎么看？
Kagermann答：我们尚未改变策略。我们经营的是混合型的模式。我们有充分的理由这么做。我们的客户要求更多弹性，所以久而久之，他们可能决定升级功能，把我们纳入后端系统。
某些方面和某些功能可采用随选模式，但这并非万灵丹。大家都从销售人员自动化开始做起，因为那方面不是很有组织，所以很合理。但你愈是进入客户关系管理（CRM）的核心，就愈难套用随选模式。人们不想跟别人分享这些信息。
然而，种种关于随选的宣传似乎已大大地扭转顾客希望付费购买软件的方式。他们不是想按实际使用量付费，就是想使用完毕后再付费。你认为授权模式未来会怎么发展？我认为将来会维持稳定。
这四年来，这个主题争论不休：授权模式应该改变吗？一切都应该改采随选模式吗？
但我跟许多客户谈过，他们表示希望拥有这些软件。他们乐意沿用现行的模式。因此，固然日后会增加新的获利模式，但核心客户仍会希望维持授权模式。过了一、两年，你可以再问我同样的问题。
问：一、两年后，你仍会留在SAP首席执行官的工作岗位上吗？你的任期将在2007年底届满，你会要求续任吗？
答：通常，这些事会在任期届满前的一年讨论。我想，大概明年第一季，会是谈论此事的时机。
问：回头再看随选和授权--有些客户抱怨花了大笔的钱购买SAP软件，却觉得似乎未完全安装和部署。有些人谈到服务导向式架构(SOA)和可扩展标示语言(XML)的吸引力，并维持在SAP上的投资，但未来的投资将以解决个别问题(point solutions)为主。你对这类客户有何看法？
答：我尚未碰过这样的客户。但倘若遇到，我会诉讼他们，年长月久之后，他们会花更多钱，因为头痛医头脚痛医脚的解决方式，会造成组成成分各异的混杂环境，变得很难管理--即使是架构在开放的平台上也一样。
我认为，客户会设法检查、测试SOA架构的弹性，然后引进个别解决方法。话虽如此，他仍须处理维护问题和与不同的软件供应商交涉。
问：你们为后端中间件NetWeaver打造生态系的进展如何？据我所知，约有一千名独立的软件开发者在这个平台上建造应用程序，但其中有多少应用程序变成主流呢？
答：为数可观的企业已这么做了。例如，Accenture就为石油工业制作了第一款混合的应用程序(composite applications)。
我试着找寻解决方案，所以我去拜访合作伙伴，要看他们的成果。但据我所知，这其实不是轻量级的混合程序，而是非常大型的应用程序。
即时通讯(IM)、维基(wikis)和博客，都是从消费者市场发迹的，然后再延烧到企业界。当然企业用户希望增强这些程序的功能和安全性。
问：有朝一日，SAP会不会也这么做，也就是先销售消费者应用程序，期望日后这些产品能打入企业市场？
答：今天许多人是这么想的，但我不以为然。大多数公司作决策是由上而下的，而不是循民主过程由下而上。
就我们的例子来看，企业应用程序是用来经营生意的。这和拥有一些好用的功能，和协助员工提高生产力的目标，是截然不同的。SAP软件用来经营生意，如果应用程序当掉，公司业务就停摆。不同点在此。
客户选择我们，是因为他们信任我们能让他们的业务维持运作。客户下的部分赌注是，公司的成功运营仰赖我们软件发挥出应有的功能。这是不同点。我认为，从非攸关运营(non-mission critical)的功能移向攸关运营(critical)的功能，是可以办到的，但无法反其道而行。
问：你对博客和维基的看法如何？
答：原则上，我认为那很好，因为能让人们分享信息和知识，而这总是好事。
问题是，这些知识的品质如何？总要有个人为此负责。假如涉及影响顾客至深的领域，那么我认为，还是办公室的资源比较可靠。
一、处理顺序图 二、处理说明 1、程序首先执行INITIALIZATION 事件； 2、接着执行AT SELECTION SCREEN OUTPUT事件(也就是PBO) ，在这个事件里你可以通过修改系统默认screen内表修改屏幕的某些属性；PARAMETERS: TEST1(10) MODIF ID SC1, TEST2(10) MODIF ID SC2, TEST3(10) MODIF ID SC1, TEST4(10) MODIF ID SC2.AT SELECTION-SCREEN OUTPUT.LOOP AT SCREEN. IF SCREEN-GROUP1 = 'SC1'. SCREEN-INTENSIFIED = '1'. MODIFY SCREEN. CONTINUE. ENDIF. IF SCREEN-GROUP1 = 'SC2'. SCREEN-INTENSIFIED = '0'. MODIFY SCREEN. ENDIF.ENDLOOP. 3、系统将屏幕输出
周三，微软和企业软件巨头SAP宣布在广泛领域内达成一项协议，采用Web Services整合双方产品.
据微软的一位高层官员称：该协议更加紧密地融合微软的.Net开发软件同SAP公司的NetWeaver集成服务器，从而有助于大型企业方便地将其SAP应用系统和微软的办公软件以及其它基于Windows的软件结合起来。
该协议是在周三美国新奥尔良市举办的SAP Sapphire用户大会上公诸于世的，这是双方现有10年合作关系的一次延伸，却双方产品的技术整合意义深远。微软和SAP将在重叠市场上对双方知识产权交叉许可。此外，微软现有工具就可以构建SAP软件。
据业内分析人士透露，该协议将使双方互利互惠。ZapThink分析师Ron Schmelzer说：这将有助于SAP充分利用微软开发工具构建SAP应用程序，而在过去则由于专用接口而并非易事”，对微软而言，该协议有助于该公司介入大型企业领域。
由于在基于Windows的服务器上布署SAP软件的企业与日俱增，所以该协议意义尤显突兀，双方估计约有3万多SAP安装在Windows服务器版软件上。SAP公司的软件开可以运行Unix和其它操作系统的机器上运行。
微软高层也很快表示，该协议对于Web services技术意义非同寻可，Web Service技术则一直处于微软在近4年内的战略核心地位。然而，也有一些分析人士认为，只有软件厂商在其产品中全面支持该技术之时也正是大型企业采用该技术之日
明天将会怎样？
. 微软日益把Web services作为合纵联盟其它战略合作伙伴的王牌。该公司于4月份和Siebel系统公司也达成一项类似协议，Siebel公司专注于客户关系管理软件开发。Rudder称在该领域还将有源源不断协议。
该协议拓展了微软的Windows以及.Net架构软件，而无损于该公司自己的企业应用软件计划。
近年来，微软在构建企业资源计划(ERP)和客户管理上投资不惜余力。一些业内分析人士认为，今后几年微软和SAP将在争夺大企业将达到白热化状态。
微软平台策略纵经理Charles Fitzgerald说，SAP公司和微软还将在企业应用领域保持竞争，并称：“这实质是基于平台的协议。我们其实在自己的企业方案(部)存在之前就和SAP展开了合作”
Fitzgerald还说，SAP公司和微软估计双方在企业应用市场仅有1%的重叠。
明确任务
该协议还明确了SAP和微软在分工： 本夏季，开始测试工具软件，开发人员借助于此类工具可以采用微软的Visual Studio.Net构建出SAP Web门户应用程序。
为SAP提供一个新版本的SAP.Net创建器，从而将SAP应用程序和微软.Net衔接在一起。
在微软所谓的先进Web services协议上加以合作，以处理SAP NetWeaver事务。微软、IBM在去年引入了此类先进Web services理念。
打造集成Office和SAP应用程序的示例代码和软件开发包，这种支持延伸到微软即将于2006年推出的下一代Windows版本、Longhorn。
整合SAP NetWeaver、微软Exchange以及Windows SharePoint服务软件。微软称，该公司将于今年底之前发布整合这些产品的软件。
此外，双方还将派出各自人员在SAP总部德国的Walldorf组建一个技术支持中心。SAP公司和微软将在市场、销售、出版技术文档以及市场基金等诸多方面全方位合作。
编者按：NetWeaver的未来几乎就是SAP的未来。Netweaver是SAP所有产品运行的开放性技术平台，着眼于实现新型企业应用构架。为完善这一平台，SAP先后收购了A2i、TomorrowNow、Lighthammer、Khimetrics、Pilot等软件公司，并将其产品整合到NetWeaver平台的解决方案中。SAP不断扩大在应用领域的优势，以应对与甲骨文、BO、微软等公司的竞争。在这次Sapphire大会上，SAP继续大力推介NetWeaver，同时宣布了面向中型市场的策略。为了持续增长，SAP正在推出更适合中小企业的产品，并大力拓展中国、印度、巴西这样的新兴市场。
在从ERP领域向基于组件服务的组件架构世界转化的道路上，SAP正在稳步前进。
4月22日至25日，数万名SAP用户齐集亚特兰大参加SAP的Sapphire 2007大会，SAP向在特定垂直领域发展的合作伙伴推介了NetWeaver平台。
每家商务软件公司都表示它可以提供及时更新的web服务，来保护现有的应用软件投资。“企业SOA”正是SAP在这方面的行动，它借助于采用Java和.net技术的中间件平台NetWeaver，为企业提供web应用服务。“自2003年我们开始谈论NetWeaver时就开始谈论‘企业SOA’了。我们对此有稳固有力的路线图，从未有过犹豫。”SAP产品和技术副总裁Bill Wall说。
SAP将继续沿着On-premise（内部部署）软件和SaaS（软件即服务）之间的道路前进。和微软和甲骨文等其他传统商务软件商一样，SAP也正在考虑SaaS交付模式。Wall指出，“对我们来说，随需应变不止是关于CRM的，也是关于SRM（Supplier Relationship Management，供应商关系管理）的。我们已找到其中一些随需交付的方法。”
SAP将继续在中型市场倾注力量。公司宣布了一个ERP的新托管版本，代号A1S，因为规模太小不够采用MySAP和All-in-One的公司，可以选择A1S。届时，Business One、All-in-One和A1S将共同组成SAP面向中小型企业的产品线。
甲骨文正在把Siebel的随需CRM投入市场；微软正在研发客户自主管理的CRM Live，也有由伙伴为客户托管的ERP和CRM产品。所有厂商都渴望表明，SaaS是他们能顺利推进的交付模式中的一种。
欧米茄集团是SAP在Business One方面的合作伙伴，其CEO Forrest Koch对此很警觉，他说，“我们已经看过ASP（Application Service Provider，应用服务提供商）的模式，它与现在的SaaS是一样的。我们看见NetSuite公司在做SaaS，Intuit公司也试图做，但是，当你看中型公司的成本，你就会发现，他们不需要它。如果有人买了Salesforce.com的服务，他们还需要定制，最后成本还是相当高。当我和Salesforce.com的用户交谈时，他们希望这些服务能集成到Business One。”
Koch说，简言之，中型公司对于功能更少、但与他们的业务流程集成度更高的软件更感兴趣，SAP的Business One即是这样的软件。
在这次Sapphire大会上，SAP还宣布了其他交付模式——应用组件。这些方法把必要的硬件和软件绑定在一起，经过调试后适应特定的应用。随着虚拟化和其他降低成本的趋势的发展，客户希望为硬件和软件单独付费，也不想为那些未开通的功能付费。SAP已经通过“商务智能加速组件”试水这一领域，这一产品是在英特尔、IBM和惠普的帮助下开发的。
升级在企业IT的生命周期中是不可避免的，但是SOA的益处使得NetWeaver的实施令人信服。
马克·吐温曾经说过，死亡和交税是人生之中不可避免的两件事。我想说的是，在应用软件的生命之中，升级一样不可避免。你可以推迟死亡和升级，但是却不能完全摆脱它们。
在2002年末，SAP发布了SAP R/3 Enterprise (版本 4.7)。许多顾客考虑到某天他们必须升级到最新版本，直接提前完成了升级。
但是，SAP R/3 Enterprise发布的尘埃尚未落定，一种被称为SAP NetWeaver 2004的新范式被提出了。常识告诉我们应该升级到最新版本，尤其是在新版本有多重价值的情况下， NetWeaver 2004就是这样的新版本。但是，上千记的客户却并没有打算升级其R/3 4.6C, R/3 Enterprise 4.7或者更早版本。所以，是应该保持不升级状态，还是应该下定决心立即升级到NetWeaver 2004，以便能够应用其新功能部件呢?
如果只允许推荐一个使升级值得的新功能部件的话，我认为那将会是它能够以服务的形式构建应用程序的能力，这些服务对外开放并且能够被后继行业标准规程重新利用——即面向服务的架构(SOA)。
随之而来的SOA和企业级SOA
SAP并不是加入SOA潮流的第一家主要软件厂家，而且也绝不会是最后一家。但它是一直在提供配置企业级SOA方面非常成功的一家。大多数人对于SOA的概念都已经很熟悉了——基于服务的架构，将商业规则和流程封装从而能够向公众应用和再应用开放。如果这种架构处于企业级上，概念就扩展为企业级SOA(ESA)。利用这些企业级服务，SAP和其客户、商业伙伴等合作者就可以构建可以重复应用的服务来封装商业流程和规则，并且可以用来构建新的流程和规则。
在本世纪初，SAP公司面临的境况是：公司销售额和利润增长缓慢; 甲骨文公司不断吞并竞争者并且市场份额不断增长，SAP需要保持与它的竞争能力; 需要精简产品线并且降低SAP软件的使用和维护费用; 从专利向开放标准变化; 像SAP前产品技术总监Shai Agassi一样的善于想象者的地位提升等。
NetWeaver正是这一连串需要和观点的结果。企业级SOA是NetWeaver包的主要价值命题。不愧其声誉的是，SAP并没有让样式和宣传取代内容成为主要竞争力，而是集中精力交付了一个非常有潜力的技术范式。
什么是SOA和ESA?
除了“应用程序作为服务”概念以外， SOA并没有唯一的定义。但是这一概念并不是全新的——即应用诸如XML, SOAP, WSDL和 UDDI等开放标准和技术进行绑定，开放外部访问，并且在被架构为服务的商业功能之间进行交互。NetWeaver通过应用其网络应用服务器6.40(Web Application Server 6.40，即Web AS)支持所列规程来实现上述功能。Web AS是NetWeaver的后端服务器和技术基础。
这些规程并不是全新的，很可能您的企业已经在将其作为基于网络的应用程序而使用。如果您对于企业在IT方面的核心能力做过记录的话，就很可能会发现这些技术和概已经存在，而且更重要的是，可能已有很好的认同度。
宣布从SAP辞职后不久，Agassi在其博客上讲述了ERP, NetWeaver和企业级SOA的联系。在解除了公司规范的束缚后，他对其中的关系给出了公正的说明，标题是“ERP重要吗?”
客户反应
与我交谈过的SAP和其他主要SOA厂商的大部分顾客都认为SOA和ESA的概念过于抽象。有些人表示他们不会在像SOA这样模糊的概念下就决定使用或升级到NetWeaver 2004。
如下是其中一些争辩最激烈的话题：
我们所有的配置和开发是不是都会过时?
构建企业级服务是不是与实施新的SAP模块类似?
我们在ABAP方面的能力是否已毫无意义?我们应该招募Java 开发者吗?
通过NetWeaver 实施SOA会额外收费吗?
这些问题显示了NetWeaver和SOA的低认知度，这并不值得奇怪。在NetWeaver的早期阶段，有太多的理论、假设和高层次的思想，而具体信息非常少。我是第一次见到SOA和ESA的市场推广产品感到眩晕的SAP专业人士之一。还好，SAP为客户提供了一种可视化的构架以及许多帮助将想法转化为实际的资源。
建议
如果对于从ERP立场看企业级SOA来说，您是新手，那也不要绝望——大多数人都和您一样。但是，请不要让对技术和(或)NetWeaver的相对不熟悉成为您升级到NetWeaver并应用它的阻碍。
转换到企业级SOA并不是一件容易的事情，我自己以及其他专业人士的经历可以说明其中的挑战大量存在。但是，SOA对于在当今超竞争的全球环境下使业务灵活化具有巨大的潜力。而且，SAP提供了实现灵活化愿景的的必要工具和技术——SOA能够与NetWeaver中的其他强大程序协力工作，这些程序有Visual Composer、NetWeaver Developer Studio (NWDS)、复合式应用程序框架(Composite Application Framework，即CAF)以及Adobe的交互式表单技术(Adobe's Interactive Forms technology)等。
现在是该认真考虑企业级SOA的时候了。投入耐心和努力，您的企业就能从中受益。下面是对实行SOA的一些建议：
不要把SOA看作范式更改。如果您付出应有的努力来分析组织的IT能力，就可能发现可以把SOA简单看作范围的扩张，从而使实施比想象来的容易一些。
不要让关键股东淹没在技术行话、术语和缩写之中。SOA的关键主题是增加SAP投资的回报率和降低所有者的总体成本。利用这一主题来说服执行官投资于SOA的机会比较大。请谨记，SOA更多的是帮助业务满足挑战，而不仅仅是推行一揽子技术。
不要贪多求快。尝试采用最容易的方式来获取最初的胜利并转变反对者和怀疑者的观点。也就是说，首先建立基于相对简单的业务流程的服务。最初的胜利对批评者和倡导者都会产生积极的心理影响，从而推动更广泛的应用。
遇到困难积极寻求帮助。寻求帮助的最好去处之一是软件开发者网络(Software Developer Network)的SAP服务交流区。需要更多的资源，请查询工具条。
从商业系统起家的SAP，将从众竞争者最弱的一块来争取企业客户的青睐：应用。
相较于IBM、BEA与微软大谈如何在中介软件基础架构上开发软件组件，以便建构服务导向架构(service- oriented architecture, SOA)的环境，企业资源规划(Enterprise Resources Management, ERP)巨人SAP则认为更节省成本的方法是直接提供软件服务。
和中介软件厂商叫你自己开发(软件服务)不同，我们已经帮你做好大半，SAP亚太区技术长Simon Dale指出。这样可以帮助企业省下许多建置成本和工夫。
这也是SAP与其它IT软件大厂切入SOA市场的策略不同处。BEA、IBM及微软，都拥有强大的中介软件及基础架构，同时强调简易、弹性、可协作的开发工具提供企业在软件平台上自行开发程序组件。另一方面，从应用层来实践SOA的则只有甲骨文及SAP; 两家商用软件大厂自数年前一改旧式大型软件的架构，朝向组件化、模块化的软件服务组成的松散耦合(loosely coupled)系统。
其中，甲骨文原已有中介软件及ERP、CRM等应用系统，而ERP应用出身的SAP更是于2005年推出基础架构软件NetWeaver。
在这种系统上，企业可以在必要时订阅特定或原已存在的服务，如银行推出线上刷信用卡，则订阅身分认证及支付两种服务，并把数据更新到客户关系管理系统。则银行就不用重新开发，可以节省成本及加速服务上线时间。
SAP业务发展协理陈平佳强调，SOA不只是技术的玩意，而必须和商业行为结合。应用层上的服务组件及商业流程才是重点，他说。
在SAP的ESOA(Enterprise SOA)愿景下，企业以NetWeaver为基础的ERP软件配合SAP提供的软件组件，可以满足企业80%的需求。相较之下，没有导入应用，而只有中介软件的企业，则必须自行开发所有的组件，Dale表示。
SAP自2005年起，改变旗舰级软件以版本别命名方式，统一为SAP ERP 6.0，将沿用到2010年下一重大改版。期间并免费推出Enhancement Package的方式，不断增加新的服务组件。从2006年第四季，以一年二季的速度释出。到目前为止已推出一个，包括人力资源及电子发票等模块，未来五年将在推出五个，Dale表示。
随着组件的增加，未来我们可帮助企业节省85%、甚至90%的投资。他说。
而个别企业的特殊需求，则仰赖经过SAP认证的第三方软件公司推出的服务来补充。SAP自2005年大举招募ISV，目前全球有约600家取得认证，亚太区则有140家，SAP指出。
甲骨文也是循同样策略。在并购Siebel、PeopleSoft、J.D.Edwards及垂直产业的软件后，甲骨文也进行软件的重新改造，企业可在预定2008年推出的Fusion软件平台上使用软件服务。
目前SAP相较于竞争者，最大的问题或许在于客户的认识仅及于其ERP的品牌，并不熟悉NetWeaver及其新的营运模式。不过陈平佳表示，目前国内新导入SAP ERP系统均已包含NetWeaver，像是乔山科技，而也有国巨等导入NetWeaver，使用其中的模式作为应用整合或商业智能(Business Intelligence, BI)项目。
同时，SAP更自豪于产品已经上市。别人说哪一年预定推出并不重要，重要的是我们已经推出了，而且有人用了，Dale说。
NetWeaver是什么：SAP NetWeaver是下一代基于服务的平台，它将作为未来所有SAP应用程序的基础。NetWeaver包含了几项技术和组成部分：一个门户框架，商业智能和报表，商业流程管理（BPM），集成，自主数据管理（MDM，Master Data Management），一个公用运行时间应用服务器（common run-time application server），以及SAP应用开发和管理平台。
SAP公司宣称NetWeaver可以提供人，流程和数据与SAP应用和信息的集成。而且， SAP NetWeaver是SAP为其客户提供复合应用程序的基础。 这些通常被称为xApps的复合应用程序将用SAP NetWeaver工具来编写和控制。它们将使用SAP应用程序中很普遍的现有功能为SAP产品家族来扩建新的功能。
NetWeaver不是什么：首先，NetWeaver不是一家公司可以自行购买或升级的产品。而且，它没有选择的余地。
NetWeaver不是IBM，微软或BEA的一个通用基础设施替代物。它不是一个通用开发平台。它不会替代各公司已经用于开发与SAP无关的定制应用程序或进行非SAP应用程序间的集成的技术。SAP不会用J2EE重写其专有的开发语言——ABAP。虽然开发员将仍须懂得ABAP， NetWeaver将会包含其代码以便在J2EE和.NET环境中进行互操作。NetWeaver集吸引力，强制性和不可避免性于一身
不管是否愿意，SAP客户最终将采用NetWeaver。事实上，当各公司升级SAP或者采用如CRM 4.0等新的SAP应用程序时，不管他们是否知情，他们都已获得了NetWeaver。
尽管如此，各公司可以控制在何时以及如何使用和管理NetWeaver。虽然SAP把NetWeaver看成是一个它和它的合作伙伴们在上面编写和配置新的复成应用的平台，它的客户并不一定想这样。NetWeaver是SAP的一个架构，但对SAP的客户来说是否如此呢？
SAP关于NetWeaver的动机非常简单：
通过避免被看成是一个其它系统可以简单地访问的匿名数据源来保持收益和帐户控制。通过增加和每位雇员，更重要的是，与外部顾客的关联性和适用性来增加收益。一个用于企业间操作的关键设施的建立可能代表了最大的增长机会。
在每个层次上--从数据到中间件到台式机--SAP都在发挥着它的控制作用。它也在确保客户为每位用户与系统的互动支付费用，哪怕很小。因此，当一位SAP客户将数据存入或取出SAP系统的记录时，NetWeaver将作为控制数据互动的装置，起着SAP数据高速公路上的收费站的作用。 SAP将向客户收取费用，不管他们是采取何种传输方式： 直接的应用程序设计接口（API）， 通用的企业应用集成 （EAI）， 可扩展标记语言 （XML）， 或者电子数据交换（EDI）。
尽管如此，SAP还是提供了一个很强有力的理由：既然你可以从SAP获得预制集成的同样技术，为什么要使用第三方工具来管理与SAP的数据互动呢？为什么除了SAP外还要向第三方的提供商支付费用呢？目前， NetWeaver为SAP提供了最大的好处
SAP为了自身不得不开发和配置NetWeaver平台。准确地说，它不得不使它自身的开发和配置在众多应用程序中显得更有效率，对新兴市场反应更灵敏，以便降低其自身的成本和抵挡来自活跃销售商的潜在竞争。很明显，它已经从客户关系管理 （CRM）和供应链管理（SCM）市场的历史中取得了教训。
在理论上，对于SAP更好，更全面，更有效的平台对客户来说是更好的平台。但是，SAP的理想平台不可能是客户的理想平台，原因有以下几点：
没有人比SAP更以SAP为中心。另外，尽管SAP终于承认还存在其它系统，NetWeaver的明确目标就只是目前的SAP客户。 SAP将使NetWeaver适应那些视SAP为企业支柱和主要信息来源的公司和个人。其他可以不管。
我们可以预期NetWeaver首先为SAP服务，其次是主要的SAP客户，第三是异构型环境下的SAP客户，非SAP客户想也别想。会鼓励，恳求，强迫，或明里或暗里（以产品更新或新产品为伪装）迫使客户采用其框架的软件销售商，SAP绝非独此一家。例如，你可以仔细看看Oracle 9iAS和即将推出的嵌入许多应用程序的10g应用程序服务器。你甚至可以看看微软的Office System 2003。斗争就要开始，每家公司都不得不画出界线，做出选择。
当标准威胁到他们对控制权的保持时，SAP就会抵制它们。许多新兴标准--如关于portlet的JSR 168标准，就与SAP的动机背道而驰，原因至少有二：
1） 它们可能会阻碍他们自身在开发上的努力。
2） 它们使他们容易被商品化。
显然，SAP也只是想客户升级。为了建立一个新的，更有用更有效的平台，SAP必须还要制造强有力的理由让客户转到这个平台。
结论:NetWeaver平台本身作为升级理由并不充分。大多数公司会，也应该基于新的关键功能进行升级。
考虑到SAP迫使客户使用NetWeaver所取得的利益，它在为其客户开发和配置NetWeaver的时候自身获得的回报，将远大于你的。从长远来看，SAP节约的能力对客户将转化为成本的降低。
不管喜不喜欢，在使用第三方工具来管理与SAP数据互动的问题上，SAP提出了一个强有力的理由。这对于SAP在全公司，涉及所有商业功能，跨部门跨区域深入普遍使用的SAP客户来说尤其如此。其它80%会感觉他们似乎在某种程度上被敲诈了。
各位媒体界的朋友们大家早上好，再次向大家问好。非常感谢大家今天有空到现场来参加我们的技术研发者大会。我花一点时间给大家做个开场介绍，然后把时间留给大家提问题。希望我们利用这个时间做一个很好的互动。
在座的各位媒体朋友有的已经跟踪报道我们很久了，有的是新参与报道SAP的。我为大家先简单的介绍一下SAP NetWeaver和企业级的面向服务的架构（Enterprise SOA）。
NetWeaver是SAP的产品，它本身是SAP现在的企业应用软件的底层技术平台，即SAP所有新的应用跑在一个相当于在系统之上的、类似于中间件的支持平台。 SAP在2004年正式推出NetWeaver这个产品。 在此之后SAP所有的新的产品都是跑在NetWeaver这个平台之上的， 这个平台也可单独采购。
NetWeaver为SAP所有的企业应用提供了一个公共的、基础的平台，包括提供了Web应用服务器的支持、数据的存取和各种系统之间的功能等。NetWeaver还提供了许多企业级功能，包括了在人员方面、信息方面、流程方面提供集成服务，这是由很多诸如交换架构XI、主数据管理MDM等组件组成的。 NetWeaver把企业应用最常用的IT需求都定制化成产品，提供相关的功能。NetWeaver还提供了各种相应的基于Java和ABAP的开放的软件开发环境和工具。
这就是SAP NetWeaver这个产品，是目前支持所有SAP应用的基础产品，是最好的企业应用软件的开发平台、同时又为企业搭建一个基于NetWeaver的面向服务的IT架构。
企业级的面向服务的架构(Enterprise SOA)，又可简称作企业服务架构。 大家在主题演讲中已经听过介绍，我想再通过比较的方式讲一讲我们的Enterprise SOA是什么，和其他厂商谈的SOA区别在哪里。
SOA这个概念大家听的比较熟了，是面向服务的架构，实际上它的背景是基于最新的互联网的技术，把各种应用都做成Web Service，做成网上服务。 这些服务可以分散在互联网的不同地方，调动这些服务来实现IT的功能。 SOA这个概念虽然推出一段时间了，不过其他厂商通常谈的是IT底层基础架构，是一个网络的技术名词。
SAP企业服务架构增加了丰富的、实质性的内容。SAP把我们从1972年开始34年在企业应用方面的全部积累和丰富的业务知识，做成企业服务（Enterprise Service），成为企业服务架构的基础。 基于但不止于SOA， SAP在企业应用这个环境, 以NetWeaver为基础，加上企业服务库，加上复合应用组合成业务流程平台（Business Process Platform）, 成为第一家和唯一一家实现了企业服务架构的软件供应商。SAP使SOA从理念性、技术性的东西变成在企业层面、在现实IT中确实被使用的东西。 它的背后体现在SAP将近上万名工程技术人员花了两三年的时间，把我们的在各个行业都占据领先地位的ERP、CRM、SRM等企业应用都在这企业服务架构基础上重新改写。与之相比，我们的竞争对手虽然随后也匆忙提出了类似的规划，但其实施和退出还需要约二年的时间。
企业服务架构的推出在业界产生了广泛深远的影响，特别是在比较发达国家IT业形成一股旋风，大家对此刮目相看。分析家评论说据此企业应用将进入一个新的发展时期，企业服务架构将成为下一阶段主要软件公司竞争的焦点，谁要是在这上面占据领先地位就有可能成为下一代软件业的霸主。所以我才戏说用三国来形容SOA是软件业竞争的荆州。这是关于企业服务架构Enterprise SOA的概念。
企业服务架构的意义是非常重要的。 现在我们把它推出来，一方面是SAP用它来搭建我们自己的软件，一方面是要建立一个生态圈，客户可以在这之上，在同一个平台上共享很多组件，灵活地搭建企业应用，独立软件开发商可以成为SAP的合作伙伴，也做同样的事情。这样可以形成非常高效、非常有活力的生态圈。 这样就解决了企业IT管理上的长期难题，到底是自主开发软件还是买现成的软件。 以前一旦选择朝东走就很难朝西走了， 而现在不需要做一个选择了，鱼和熊掌可以兼得了。现在在同样一个平台上有可能尽量采用各种商业用的软件，又同时为自己开发或者是采用其他独立软件商的软件。从这个意义来讲软件业确实进入了新的时代，这也是我们在今天向中国软件业隆重推介NetWeaver平台，进一步阐述企业服务架构的意义所在。
我给大家讲一个我的观察。 大概在半年前，当我到国外出差收集一些有关资料时，发现在那个时候可能有几本SOA的书，在阐述在技术底层SOA是怎么回事、Web Service怎么用等等， 但是基本上没有人谈Enterprise SOA。 一个月之前我再去新加坡的书店，突然发现在国外已经有了五本书，它的名字里全都有Enterprise SOA。后来我发现有两本书在中国已经翻译准备出版了。从去年开始我们开始着重讲企业服务架构Enterprise SOA，其后迅速成为业界大家关注的焦点。这五本书里有两本是与SAP有关的人员写的，其他几本并不是SAP的人写的，而是其他软件从业人员看到了企业服务架构带来的冲击写了这些书， 我想很快会有更多的书问世。 我想用这个故事跟大家分享一下企业服务架构的快速发展以及可能带来的影响。
最后我给大家介绍一下SAP产品进展的情况。
首先按照我们的技术路线图，SAP各个方面的产品都在不断地前进，在过去半年中，我们推出了好几个新产品，我们推出了在线的客户关系管理（CRM On Demand），又和微软合作推出DUET（二重奏）产品。 二重奏是把SAP后台企业应用的数据通过微软的办公环境展现给业务用户，这个产品是今年5月份推出的。
除此之外，SAP于8月份正式推出了基于企业服务架构复合应用的企业分析软件（xApp Analytics）。 这类软件的功能是把信息交给业务用户，让信息能够直接为企业的经营、运营、决策做支持的软件，传统上属于商务智能（BI）的范畴。但是我们提供的这类复合应用分析软件，它和别的传统商务智能软件不同点在于我们的分析软件是内嵌在业务流程内的，可以直接影响业务流程，不是说事后看一看这些数，而是这些数直接在过程中可以直接影响控制你的业务流程。这些都是相当有意义的发展。
企业应用是软件类非常大的门类，对整个行业有深远的影响。最近SAP已包装了500个高端的企业服务Enterprises Service，如财务服务、人力资源的服务。以后客户可以直接调用这些包装好的服务，客户和其他厂商也可以调用这些服务。刚才我和祥麟在讲，一个非常恰当的比喻是将软件的企业服务架构化类比于电路的集成化。集成块(IC)本身也是功能模块化设计的，但它是更复杂电路的基本组件。集成电路的出现从根本上改变了电子行业。设计一个个的集成块，把他们组成电子设备，而不是再从电阻、电容、电感、晶体管等基本元件来组建电路。以后软件业的工作就是要设计这些“集成块”和利用这些“集成块”，这些“集成块”就是企业服务（Enterprise Service）。 老的软件行业正在合并和兼并中死去，一个基于企业服务架构的新的软件行业正在诞生中。
其他的情况新闻发布稿里都有，下面我和祥麟会非常高兴跟大家进一步交流，欢迎大家提出各种各样的问题。谢谢大家！
NetWeaver,是SAP推出的企业应用软件的底层技术平台，作为一个类似于中间件的支持平台，它不但提供强大的企业级SOA架构服务，还支持SAP所有新的应用软件。
对于SOA的概念，大家都已经很熟悉了—基于服务的架构，将商业规则和流程封装从而能够向公众应用和再应用开放。如果这种架构处于企业级上，概念就扩展为企业级SOA(ESA)。
SAP TechEd (SAP 全球技术研发者大会 )，作为SAP 全球最重要的技术类大会，拥有10多年的悠久历史。今年，SAP TechEd 来到中国上海。在这里，您将了解如何运用SAP NetWeaver的力量及其灵活性对您的业务流程进行创新和改变。并与产业链中的技术专家、客户代表、合作伙伴以及业界同行进行交流和学习，分享由 SAP 顶级技术专家的专业知识和观点。【编辑/付江】
SAP NetWeaver可将客户的IT资产转化为战略价值推动因素。SAP推出的SAP NetWeaver和企业服务架构（ESA）为Web服务从概念转变为业务现实规划了一个蓝图，同时降低了运营成本。
SAP NetWeaver是近年来具有革命意义的基础应用和集成平台产品，建立了面向服务的新的SAP企业信息架构，提供了极强的对各层面的IT标准和行业标准的支持；降低了企业的IT总体拥有成本（TCO）。从某种意义上讲，无论对SAP公司还是整个ERP业界，SAP NetWeaver所引导的技术变革将与当年客户端/服务器的变革具有同样重要的历史地位。
本书亮点：企业服务架构、SAP企业门户、SAP商务智能、SAP交换架构、SAP NetWeaver开发者工作室、互通性、SAP移动架构、SAP主数据管理、Web应用服务器。
（3）主数据管理：
在NetWeaver的四个集成层面上，MDM处于第二个层次，即进行“信息的集成”。
对于一些具有分布式IT 架构的公司来说，统一一致的主数据管理是经营成功的关键保证。但是如何实现统一管理却是一个大的挑战。许多公司发现在公司内部不同地点、不同系统内存在着重复冗余的数据。这些可能带来费用的增加、扰乱业务，并且影响客户服务水平。
幸运的是，SAP 主数据管理(SAP MDM)-SAP NetWeaver的一个组件允许公司存储、发展和整合主数据，同时在整个IT 环境内进行一致性发布。通过跨不同地区的异构系统，SAP MDM充分优化现有IT投资，减少数据维护的成本。
MDM 提供三种方式的主数据管理：
内容整合：子、分公司各自拥有体系及完全的数据维护权，中央整合数据,建立映射以进行全局分析
主数据一致化：总公司创建，子、分公司可独立创建，并和总部进行一致性检查
集中主数据管理.：总公司集中创建，各子、分公司使用
3．SAP 交换基础设施-XI：
现在的企业普遍建立了很多大大小小的系统，公司需要有效的集成这些系统。同时随着互联网的出现，企业协同的要求也是日趋强烈。以前只能在公司内部网上操作的一些业务流程，现在要求能够通过互联网运行，例如供应链计划、寻源和需求预测。有些企业的做法是使用新技术的系统套件替代旧系统。但实际上更多企业没有时间和成本全面升级旧系统，或者在全球范围内进行大规模全面的系统替换。从利用投资的角度来看，企业也必须从现有异构系统投资中萃取价值。因此为了达到目标，不同供应商开发的系统需要进行集成，并且嵌在一个集成平台架构上。
为了支持新一代的应用系统，集成平台必须提供更深的功能不仅仅是消息队列传递和数据转换。公司需要跨越不同的企业或者现有系统，实现更进一步的协同业务流程。就像以前用实时处理替代批量处理的做法一样。SAP已经开发出了全新唯一的基于Exchange的协同和集成技术，提供革新式的自动化业务流程方法，使用恰当的Web 服务，优化现有投资。
SAP 交换基础设施（Exchange Infrastructure,以下简称SAP XI），建立在完全的开放Web架构上，使得管理来自不同供应商、高度异构、应用不同技术的系统成为可能。SAP XI包括技术功能，例如web服务的查找、队列、匹配和路由，以及业务流程管理的管理框架。
提供一个基于XML技术的信息交换架构，集成SAP的各类系统，包括外部非SAP系统，支持开放标准，如XML,WSDL和SOAP;
通过预配置的业务流程模型，传递SAP行业知识（包括业务流程和集成）给用户；
提供一个集成的工具集，支持企业建立新的业务模型，维护所有集成相关的信息（“共享集成知识”）。
2007年8月14日，北京讯— SAP公司日前宣布，将针对SAP Business One管理软件提供两种促销套餐“敏捷财务”和“全效管理”，只需不到10万元起，中小企业用户就可以得到SAP大师级的管理解决方案！SAP在此次促销中特别提供了分期付款的灵活方案，同时，客户还可以在截至到2007年10月31日之前的促销活动期间，凭其既有的业务管理软件，享受到这两款产品更优惠的促销价格，让更多的中小企业轻松享受SAP的优质产品和服务。
实现信息化管理是所有企业的向往，但中小企业由于预算压力和IT人员的缺乏，普遍对企业管理软件欲购不能。深谙企业管理之道的SAP了解小企业和大公司的不同，而保护前期IT投资，对中小企业化解IT预算有限难题以及提高投资回报率极具有重要意义。对此，SAP从市场的实际需求出发，在此次促销中为Business One明确了固定的价格、固定的产品模块以及服务范围，使它像真正的套餐一样一目了然，让客户更放心选择。同时，SAP充分考虑到，财务软件和业务管理软件在中小企业中已经有不少应用，完全舍弃既有的系统必然可惜，但各类模块之间缺乏集成的事实，又造成了管理环节之间存在的诸多“漏洞”。因此SAP在此次促销中，不仅允许买家通过“按揭”方式尽快用上一体化的集成式Business One管理软件，而且客户还可以在促销活动期间凭既有的业务管理软件得到特惠的折扣。这种细心和体贴的考虑，极大地保护了中小企业的IT投资。
参加此次促销的SAP Business One“全效管理”套装，包含了SAP Business One的全部模块，是一款包含标准且固定模块的产品，包括业务流程管理、销售与分销、采购与库存、财务管理、客户关系管理、生产管理、人力资源管理、报表、成本控制和物料管理等等，通过集成的方案为企业堵住管理“漏洞”。另外一款“敏捷财务”套餐，是一款即买即用并包含标准且固定模块的产品，包括会计财务功能为核心，集中了应收/应付、成本会计、财务报告、交易记录、财务核算、发票管理、现金流量表、外汇计算等多种功能。基于SAP系统良好的可扩展性，客户未来可以根据实际业务的发展需要，在轻松添加其他业务管理功能的同时，确保信息的实时性和企业整体管理的完整一致。针对两种套餐，SAP及其认证的合作伙伴都将提供为期两年的产品升级维护和热线支持，消除了客户的后顾之忧。
SAP Business One界面直观一致，可快速实施和投入应用，很好地满足了中小型企业的需要，更重要的是，它使企业能够在规范业务流程和优化管理的进程中，实现持续的发展。目前，众多选择了Business One的中小企业客户已经从中受益，感受到以低廉成本快速部署SAP应用软件后带给企业管理的便利和高效，正如深圳市紫东房地产经纪有限公司总经理张先生所说：“SAP Business One‘敏捷财务’套装具有灵活的自定义功能，它快速打破公司各部门之间的信息壁垒，使管理层直观地审视财务大局，透析企业经营状况。同时，套装贴合企业预算，按需购买和完善的售后服务体系使得紫东这样年轻的企业也能够畅享世界顶级管理软件带来的管理变革。”
特别值得注意的是，Business One产品的研发工作是由SAP中国研究院所负责的，因此更为贴近本地客户的实际需求。同时，大力发展本地合作伙伴网络，也表明SAP立足本地，共建和谐、健康生态系统的思路正在显现出积极的成效，本地的中小企业客户也将从SAP及其伙伴那里得到更好的服务和支持。这一点不但已经从SAP第二季度在渠道业务方面取得的良好业绩得到了证明，也赢得了SAP合作伙伴的认可，“作为SAP Business one产品的主要合作伙伴，我们很高兴看到SAP公司对中国中小企业市场的高度重视，相信通过这样的一个战略性的市场活动，会有更多的企业体验到SAP Business one产品的先进管理理念和专业的咨询服务为企业带来的真正的管理效益。”上海达策信息技术有限公司李江滨总经理说。Business One正在不断赢得越来越多中小企业的青睐。可靠的技术、全面的功能、优惠的价位、完备的服务，使SAP Business One成为中小企业采购决策者首选的管理软件。
各业务部门相对独立，数据不共享的问题已经困扰了大连圣诺的王总很长时间了。如今，大连圣诺正试图借助强大的SAP Business One企业解决方案及其合作伙伴北京华软新元的帮助，解决这些困扰并打造企业坚实的管理基础。
业务扩展挑战管理基础
大连圣诺食品有限公司是友兰企业集团下属的一个中外合资企业,它成立于1997年7月,企业以生产各种罐头和速冻食品加工为主，产品销售全国各地，出口日本、韩国、加拿大、非洲国及欧盟诸国。经过这几年迅猛发展，大连圣诺取得诸多成绩，产品先后被评为省市名牌产品，取得了HACCP认证及欧盟注册，通过了ISO9000认证和市场准入（目前首家在全国罐头行业取得市场准入资格）。
随着市场空间的逐渐扩大以及业务的不断发展，市场环境也千变万化，大连圣诺明显感到企业的信息滚动速度太慢，甚至很多是不共享的。虽然之前公司内部也有局域网，但各业务部门并没有形成一个统一的平台，当初也为了各部门自己的需求运用EXCEL工具进行数据管理，虽然有一些效果，但之间的数据都不是共享的，而且很多都是重复录入，工作效率很低。更重要的是，无法使财务数据与业务数据进行链接。这样在财务数据上就不能实时反应出业务数据发生的变化，不利于公司进一步的发展。这个时候，加强企业的基础管理就被王兆林总经理提上了日程。
恰好去年年底，大连华软新元和SAP在大连共同举办了燎原计划的发布会，大连圣诺第一次了解了SAP Business One。虽然之前王总甚至没有听说过SAP的名字，但通过对SAP公司背景及实力的了解，对其信心大增，特别是相对于国内软件厂商，SAP的后续发展能力还是非常有优势的。其次，SAP Business One是一个集财务、销售、采购、库存、银行、客户关系管理、生产配套和成本管理为一体的企业管理解决方案，能够适应复杂业务应用、具有良好的开放性和扩展性的功能特点使企业各种业务数据高度集成共享，避免重复投资信息建设。而这些都是王总仅用了一个月时间就选择SAP的决定性因素。
管理初显成效
由于大连圣诺的产品是以罐头和水产品为主，夏秋季是生产旺季，生产压力较大，所以王总选择在淡季时进行实施。大连圣诺开始时就确定了自顶向下定规划，自底向上搞实施的原则，首先从业务流程上入手，完善了从采购、销售、库存到财务、应收帐款的过程管控，实现了多角度的查询和分析，同时还可以方便的了解整个业务发生的过程；业务流程理顺后，大连圣诺进一步加强了对生产成本的控制，生产成本精细到每一天，使问题及时发现并得以改善。
虽然目前正式启动SAP Business One时间不长，但其基于业务流程与财务流程高度集成、强调财务信息对公司全部业务的实时监控和分析已经初显成效。这样在大连圣诺企业内部，所有的业务、财务都在一个平台上运作，减少了相互对帐的时间与差错，同时业务部门能实时看到自己业务的相关数据，加快了决策的准确性，为公司的发展打下了坚实的基础。
在实施过程中，王总感受最深的是大连华软新元公司的几位实施顾问的敬业精神，看到他们的这种精神，我们对项目的成功更有信心了。
看重未来表现
作为一个中小企业用户，王总对信息化的理解表现出非常少有的成熟心态。SAP Business One不是一个简单的软件，而是种工具，怎么用以及用得更好需要我们用户去发掘。他认为先把基础平台搭建好，以后陆续实现相应的功能。应该客观地看待信息化的成效，信息化不能急功近利，关键是今后企业自身管理水平的提升，以及如何与系统有效地结合起来，这都是需要时间的。只要坚持用，然后不断发现问题并完善它，毕竟这套系统中很多功能还没有被挖掘出来。这些都为我们公司的第二次发展创造了有利的条件。王总非常看好SAP在中国中小企业市场的前景，我们认为，既然SAP要做中小企业市场的业务，就一定有实力做好。
目标用户
有一定信息化基础，有升级改造需求的中小型企业。
典型实施
作为一家汽车维修设备制造厂商，青岛金华工业集团经过创业期与成长期后，步入平稳发展期。此时，信息无法在各业务部门间及时、有效地传递已成为制约企业发展的主要问题。企业亟需有效的工具进行管理，如进一步有效地加强质量控制系统，提高分销管理和物流管理水平及按时交货能力；采用灵活的生产方式，根据订单、生产线的不同情况计划生产和排产；进行企业生产成本控制，从多维角度进行企业赢利状况分析等。
完成ERP系统上线，企业已初步构筑起信息化核心应用平台。在系统运行一年多后，中科对ERP项目做了投资效益分析。其中，对系统的量化评估是：各生产工序的成本降低了5%～8%，平均存货降低了13%，劳动生产率提高了16%，按期交货达到了95%，短缺料次数降低了70%，加强了企业的内部审核。存货准确率也从以前的70%提高到94%以上，有效降低了管理成本。金华集团决策层主要通过SAP Business One在公司内部的运转，得到详细的企业运营数据，改变了他们的决策方式。系统同样转变了管理人员的工作方式:将财务会计转变为管理会计，加强了对公司整体情况的掌握。除对业务层面管理的提升外，SAP Business One系统的实施提升了企业员工素质，转变了管理人员的工作方式，提高了大家团队合作精神与协同工作意识。
软件特性
全面集成的业务功能 SAP Business One中文版提供的业务功能覆盖了账务、销售、采购、库存、银行、客户关系管理、生产装配和成本管理等企业管理方方面面的内容。企业的各种业务数据高度集成共享，避免重复投资信息化建设。
满足中国本地化要求 SAP Business One中文版可使用多项应用方案来处理企业的所有业务流程，并且符合中国法律和应用习惯的要求，囊括了中国会计制度以及会计流程中的特殊要求，例如凭证审批、凭证冲销、增值税的处理等。
开放的接口 使用SAP Business One中文版提供的标准接口，用户可以方便地对该方案进行扩展,并与mySAP商务套件解决方案或客户已经使用的其他IT系统集成。
友好的用户界面 SAP Business One中文版的界面采用用户熟悉的Microsoft Windows风格，其清晰易懂、设计布局合理的界面让用户使用起来非常方便，降低了软件的培训成本。
在线报警、审批功能 用户可以在系统中灵活配置工作流程,例如对销售过程中的报价审批、采购过程中的审批等。根据用户配置，当销售折扣超出权限范围，系统将自动发E-mail或SMS信息到相应的管理者，并且可以对超出的折扣重新进行审批。
报表分析工具 SAP独创的具有专利权的“拖拽相关”技术使用户能在桌面上拖动不同数据库中的信息，通过鼠标就能完成大量复杂的业务分析活动。
与Office工具灵活集成 SAP Business One中文版能通过与桌面工具链接来访问电子邮件，或直接创建新邮件。所有的商业文件或交易记录都可以方便地转换为电子文件或Excel表格，通过点击鼠标就轻松将这些文件发出。同时用户还可以在系统中为某类文件某个用户建立固定的文档模版。
客户关系管理 大而复杂的客户关系管理系统并不能满足小型企业对简单实用、性价比高的要求。SAP Business One中文版提供简单实用的客户关系管理功能，可满足小型企业对客户资源、销售过程以及销售人员管理分析的要求。
编辑点评
SAP中小企业版所说的“中小企业”可能比很多国内软件企业覆盖的范围要高端。在SAP的中小企业版推出的时候，小企业指的是年营业额5000万元～5亿元的企业，而年营业额5亿元～50亿元以上的企业是中型企业。现在，这一概念虽已模糊，但足见他们对中小企业的态度。他们并不关心没有任何信息化基础的企业，他们更关心的是已经初步使用过信息化，但是希望能够通过使用信息化提升管理的中小型企业。即他们更多的是瞄准已经使用了国内管理软件但是觉得不够满足的用户。
SAP早已不认为自己是个软件企业，他们觉得自己长处在管理，而IT只是一个手段。因此，SAP的中小企业ERP软件更注重流程，包括财务、进销存的对接和流程管理。很多用户在使用SAP之前必须经历痛苦的流程再造。SAP会用全球流行的管理方法要求中小企业。而这对于还处在管理基础阶段的中国中小企业来说，是个伤筋动骨的过程，甚至有很多用户因此放弃。不过，SAP在制造和生产端相对较弱，这点对于制造型的中小企业来说并不是一件好事。另外，SAP相对于竞争对手，价格和渠道方面较弱。毕竟它目前的渠道建设并不完善，再加上价格不菲，恐怕在中国还要有很长的路要走。
(四)其他信息 1. 客户关联
客户之间的各种复杂关系对于银行来说，是进行风险控制和管理非常必要和重要的信息，比如信用卡附属卡的申请人和持卡人，贷款的联合申请人、大额贷款的担保人等。对于企业来说，集团客户、业务往来频繁的企业(经常有转帐交易发生的两个企业客户)以及主管企业和下属企业之间的这些信息都可以帮助银行进行各种复杂的关联分析，也可以在某企业信用状况恶化或发生违约的概率变大时及时监控与其相关的其他企业，减少银行的各种损失。这些信息同时还可以帮助银行利用交易数据进行反洗钱的侦测。
2. 分组/分类
银行出于内部管理的各种需要，如市场营销、风险管理等，总是希望能够基于各种不同的标准对客户进行分组和分类，当然在不同时期这些标准和客户所属的分组都会不一样，数据仓库系统应该保存这些分组/分类的历史信息，了解客户的发展趋势。
3. 总帐/财务数据
银行的总帐/财务数据虽然不是和客户直接相关，但进行客户盈利分析时，必然会需要一些相关的财务信息，如“成本分摊”等计算就需要总帐中相关的成本数据。因此数据仓库系统为实现全面的客户分析，应保存此类数据。需要注意的是，此类信息的保存应尽量简单，不要期望能够替代或者覆盖功能丰富的财务分析系统，需要明确的是，财务/总帐数据的选择和存储是为了在数据仓库系统中进行客户分析、风险管理、绩效考核。
三)往来信息 如果说客户的静态基本信息采集是在某个时点或者某些时点就可以完成的，那对于银行来说更为重要、发生更为频繁的也是采集难度最大的就是客户和银行的各种往来信息了，如:
(四)其他信息 1. 客户关联
客户之间的各种复杂关系对于银行来说，是进行风险控制和管理非常必要和重要的信息，比如信用卡附属卡的申请人和持卡人，贷款的联合申请人、大额贷款的担保人等。对于企业来说，集团客户、业务往来频繁的企业(经常有转帐交易发生的两个企业客户)以及主管企业和下属企业之间的这些信息都可以帮助银行进行各种复杂的关联分析，也可以在某企业信用状况恶化或发生违约的概率变大时及时监控与其相关的其他企业，减少银行的各种损失。这些信息同时还可以帮助银行利用交易数据进行反洗钱的侦测。
2. 分组/分类
银行出于内部管理的各种需要，如市场营销、风险管理等，总是希望能够基于各种不同的标准对客户进行分组和分类，当然在不同时期这些标准和客户所属的分组都会不一样，数据仓库系统应该保存这些分组/分类的历史信息，了解客户的发展趋势。
3. 总帐/财务数据
银行的总帐/财务数据虽然不是和客户直接相关，但进行客户盈利分析时，必然会需要一些相关的财务信息，如“成本分摊”等计算就需要总帐中相关的成本数据。因此数据仓库系统为实现全面的客户分析，应保存此类数据。需要注意的是，此类信息的保存应尽量简单，不要期望能够替代或者覆盖功能丰富的财务分析系统，需要明确的是，财务/总帐数据的选择和存储是为了在数据仓库系统中进行客户分析、风险管理、绩效考核。
前言: 目前各商业银行都已经建设或者开始建设各自的数据仓库系统，期望能够将分散在已有各种会计系统、国际结算系统、资金系统、信贷系统和信用卡等系统中大量、完整的数据进行有效的整合，建立全行范围内数据的单一视图，实现客户关系管理、绩效考核分析、风险管理等应用，真正发挥数据的作用，为银行创造新的价值。
(一)基本信息 主要记录客户的一些静态信息，能够为银行提供最基本的客户轮廓分析，是实现客户细分的重要基础，同时也为后续进行的各种复杂分析提供数据支持(如风险管理、目标营销等)。这部分信息又主要分为四种:
1. 人口统计学信息
银行的客户主要包括个人客户和企业客户两类，他们之间可能有一些共同的属性，包括名称、状态、创建机构、创建时间等，但是由于各自的性质不同，个人客户还需要记录性别、出生年月、婚姻状况、学历、职业等信息，企业客户则需要存储行业、经济性质、法律类型、企业规模等重要信息。
2. 接触联系信息
银行要和客户进行各种往来，就需要采集客户的各种联络信息，比如住址(家庭地址、通信地址、单位地址等)、电话(住宅电话、办公电话、BP号、手机、紧急联络电话等)、电子邮箱、网址等。
这些信息从某种程度上也是进行客户细分的一种途径(如居住地是富人区的客户通常具有同类的喜好，具有同样住宅电话的几个客户之间可能存在家庭关系)，同时也是将来银行提供客户个性化服务的必要支持(如通过发送手机短信提供余额变动提醒服务)，尽管目前各银行这部分数据的采集比较困难而且质量不一定很好，但的确是客户基本信息中不可或缺的一部分。
3. 注册、鉴别信息
银行在为客户开立客户号的过程中，一个很重要的处理流程就是利用一些可以唯一标识客户的鉴别信息来识别客户，并为其分配唯一客户号。对于个人客户来说，可能是身份证、护照、军官证、士兵证、回乡证、户口簿、个人驾驶证等，而企业客户则需要记录营业执照、税务登记证、技术监督局代码、企业法人证书代码等重要信息。
在数据仓库系统中保留此类信息，可以帮助银行很方便地识别客户，同时便于快速识别有过“黑名单”和其他不良记录的客户，有效控制风险。
(二)信用状况 银行要实现对客户的全面分析，除了静态的基本信息以外，很重要的还应该包括和客户信用相关的信息，比如:
1. 信用评分/评级
每家银行可能都会根据一定的规则，对和本行有信贷往来的客户进行评分评级，同时会指定相关人员和部门在指定的周期内进行回顾，最大程度地保证信贷资产的质量，降低不良资产的比例。因此数据仓库中应该把这类重要的、数据质量好的信息保存下来。
此外，银行可能为实现全面的客户评价，会利用不同的渠道采集到客户的一些外部评级信息，比如一些上市公司在权威评级机构(如穆迪、标准普尔)的信用记录。将来随着社会征信体系的建立和完善，银行还可能会采集到一些来自社会评估机构的信用信息，这些也都应该保存在数据仓库系统中。
2. 财务信息
进行客户(尤其是企业客户)评价时，很重要的一个方面就是对客户的财务状况进行评价，因为这是一个能够直接影响客户偿还能力、从而导致银行资金流和资产质量变化的重要指标。基于财务信息进行计算和分析的方法有很多，但是数据仓库系统应该要采用一种灵活的方式存放可能采集到的各种不同的财务信息。
3. 资产信息
客户申请抵押贷款时，银行往往要求客户提供一些拥有资产的证明，同时在发放贷款时加大抵押的力度，最大程度上保证在贷款发生违约时能够尽可能多地挽回损失。这些客户的资产资产信息包括所拥有的不动产(住宅、厂房、物业等)、流动资产(现金、证券等)、库存品、珠宝等各种高价值的资产。银行如果能够及时监控这些资产的价值变动，适当配合贷款利率的调整，不失为一种进行风险规避的有效手段。
、审慎选择、量体裁衣、度身定做 银行在明确建设目标之后，如何选择具体的实施策略、制定设计的阶段和步骤呢?常见的主要有以下两种:
第一种:自主研发:银行根据以往的业务经验提炼本行业务的关键主题;再设计出本行的概念模型;然后通过具体的业务反复论证，同时考虑将来的分析需求进行基础逻辑数据模型的详细设计。
这种方法可以快速启动，完全依托本行的业务元素和规则，使用行内技术人员和业务人员比较熟悉的语言进行模型的设计，具有很好的适用性。但是整个建设周期比较长，同时往往由于经验不足等原因给项目带来一些不可控的风险，由于参与人员经验的不足，不能够站在全行的高度，从管理分析的角度去理解所有的业务以及相应的数据，造成一些局限性。
第二种:依托业成熟产品进行客户化:银行研究不同的业界模型产品，从中选择一个作为蓝本，结合本行的业务数据和应用系统进行具体的定制化。
这种方法的建设周期短、风险小，同时也能够很好地借鉴成熟的逻辑数据模型中蕴涵的经营管理理念。但是银行需要研究和比较多个业界流行的逻辑数据模型，熟悉各自的设计思想和理念，并从中挑选一个适合本行的模型产品进行客户化。
从国际、国内商业银行建设数据仓库系统的经验和案例来看，为了保证项目的成功实施，避免和控制项目风险，他们几乎都选择了第二种方法:客户化。那银行在面对众多逻辑数据模型产品进行选择的过程中主要应该都关注一些什么样的内容呢?
产品层面:
Ø 覆盖范围:模型产品应能够适合、涵盖银行的所有业务范围，可以在单一模型中能支撑金零售银行、公司业务、保险、信用卡、经纪、证券和电子商务等，满足未来混业经营的需要;
Ø 对业务发展的适应性:模型产品应有高度的概括和归纳，既满足范式化要求，又具有足够的灵活性，在扩展业务、新增品种或改变规则时，模型通过简单的调整和扩展即可适应;
Ø 对应用的支撑和扩充:模型产品不应偏向某个部门或某些专业的特定应用，要能够支持绩效管理、客户关系管理、资产负债管理、资金财务管理、风险管理等应用，并与国际金融业完全接轨，从数据接口层面支撑业界监管需要;
Ø 模型的开放性:模型产品应有清晰、严谨的模型架构，满足模块化和结构化的设计要求，真正实现数据一次导入，多次使用;
前言:逻辑数据模型LDM是一种图形化的展现方式，一般采用面向对象的
设计方法，有效组织来源多样的各种业务数据，使用统一的逻辑语言描述业务。借助相对抽象、逻辑统一且结构稳健的结构，实现数据仓库系统所要求的数据存储目标，支持大量的分析应用，是实现业务智能的重要基础，同时也是数据管理分析的工具和交流的有效手段。
需要强调的是，数据仓库逻辑数据模型特指数据仓库系统的核心基础模型，在搭建企业级数据仓库系统时，需要充分了解和分析种前台业务处理系统和应用，在此基础上进行有效的重组和整合，为各种分析应用(如客户关系管理、风险管理等)提供单一的、整合的数据基础，保证全行不同业务部门从不同的视角都可以使用统一的数据实现各自的分析需求。——担负这种数据重组和整合任务的数据模型称为数据仓库系统的“基础逻辑数据模型”。
基础逻辑数据模型建设好之后，银行可根据不同的分析应用需要(如客户关系管理、绩效考核、风险管理等)，根据应用产品和功能设计不同的分析应用模型，包含具体的、特定的分析逻辑，往往这种模型中都含有较多加工处理的成分。——这种为实现特定用途而设计的数据模型称为数据仓库系统的“应用数据模型”。
因此，不夸张地说核心基础数据模型建设的成败性会影响到整个数据仓库系统的建设乃至后续各种分析应用，应引起银行科技建设和业务分析人员的高度重视。
本文尝试从银行建设基础逻辑数据模型的角度出发，分析、探讨建设过程中应该考虑的主要因素、建设的方法以及注意的问题。
一、整体规划、明确目标、合理定位 银行建设数据仓库系统时应充分明确建设目标，核心的逻辑数据模型是对银行业务的高度抽象、能够提供对关键业务数据的组织和整理，建立一套完整、统一、规范的标准，以便进行各类分析。一个好的核心基础数据数据模型应该满足以下条件:
Ø 概念上:具有高度抽象的、中性的、可共享的的概念，可有效、全面、完整地适应与涵盖银行现有的业务范畴以及数据范围;不针对某个特别的应用而设计;
Ø 结构上:应是稳定的、灵活的、可扩展的;能以满足第三范式的方法构建模型，存放最详尽的数据，保证足够的灵活性，适应复杂的实际业务情况，在业务发生变化或者新增数据源时易于扩展;核心结构在很长时间内应保持稳定性，便于回答不断产生、不断变化且无法预先定义的业务问题;
Ø 表现形式:应是规范的，易懂的;包括各类命名规范，业务规则定义，度量方式等。使用统一的业务语言进行模型设计，易于业务人员的理解和使用;也有利于IT部门和业务部门人员的沟通;
数据仓库系统的建设目的和方法不同于传统业务系统，其开发建设方式也有所不同，它的建设绝不是一蹴而就的事情，不能期望一朝一夕就可以全部完成，比较成熟的建设步骤应该是分阶段实施，逐步进行完善和增强因此作为项目起步的LDM建设对于规范和推动整个数据仓库系统的建设都将起到一个很好的促进。整个建设过程最关键的阶段就是项目的最初阶段，应将工作重心放在搭建模型框架、建立模型设计思想和培养模型设计人员三个方面。
明确了建设目标，具体实施应该如何开展呢?
可查询的分区视图
CHECK 约束强制使用的分区键
在成员表上定义的 UNION ALL 视图
查询性能：查询计划仅包括解析查询所必要的成员表。
加载性能：可高效地直接将数据批量加载至成员表。
存储：尽管推荐声明主键并在主键上创建索引的做法，但分区视图不要求主键索引。
视图最多可有 256 个成员表。
必须创建维护应用程序来管理分区和加载。
Microsoft 建议的做法是定义主键，并将事实表设计为本地（单个服务器上）的分区联合视图。大多数情况下，该定义会产生可更新的分区视图，但数据仓库维护应用程序应设计为直接将大多数数据批量加载至成员表（而不是通过视图进行）。
语法示例
以下代码示例用来说明定义成员表和联合视图以及将数据插入视图的语法：
-- 创建 1999 年事实表
CREATE TABLE [dbo].[sales_fact_19990101] (
[date_key] [int] NOT NULL
CHECK ([date_key] BETWEEN 19990101 AND 19991231),
[product_key] [int] NOT NULL ,
[customer_key] [int] NOT NULL ,
[promotion_key] [int] NOT NULL ,
[store_key] [int] NOT NULL ,
[store_sales] [money] NULL ,
[store_cost] [money] NULL ,
[unit_sales] [float] NULL
)
ALTER TABLE [sales_fact_19990101]
ADD PRIMARY KEY (
[date_key], [product_key], [customer_key], [promotion_key], [store_key])
;
-- 创建 2000 年事实表
CREA可查询的分区视图
CHECK 约束强制使用的分区键
在成员表上定义的 UNION ALL 视图
查询性能：查询计划仅包括解析查询所必要的成员表。
加载性能：可高效地直接将数据批量加载至成员表。
存储：尽管推荐声明主键并在主键上创建索引的做法，但分区视图不要求主键索引。
视图最多可有 256 个成员表。
必须创建维护应用程序来管理分区和加载。
Microsoft 建议的做法是定义主键，并将事实表设计为本地（单个服务器上）的分区联合视图。大多数情况下，该定义会产生可更新的分区视图，但数据仓库维护应用程序应设计为直接将大多数数据批量加载至成员表（而不是通过视图进行）。
语法示例
以下代码示例用来说明定义成员表和联合视图以及将数据插入视图的语法：
-- 创建 1999 年事实表
CREATE TABLE [dbo].[sales_fact_19990101] (
[date_key] [int] NOT NULL
CHECK ([date_key] BETWEEN 19990101 AND 19991231),
[product_key] [int] NOT NULL ,
[customer_key] [int] NOT NULL ,
[promotion_key] [int] NOT NULL ,
[store_key] [int] NOT NULL ,
[store_sales] [money] NULL ,
[store_cost] [money] NULL ,
[unit_sales] [float] NULL
)
ALTER TABLE [sales_fact_19990101]
ADD PRIMARY KEY (
[date_key], [product_key], [customer_key], [promotion_key], [store_key])
;
-- 创建 2000 年事实表
CREATE TABLE [dbo].[sales_fact_20000101] (
[date_key] [int] NOT NULL
CHECK ([date_key] BETWEEN 20000101 AND 20001231),
[product_key] [int] NOT NULL ,
[customer_key] [int] NOT NULL ,
[promotion_key] [int] NOT NULL ,
[store_key] [int] NOT NULL ,
[store_sales] [money] NULL ,
[store_cost] [money] NULL ,
[unit_sales] [float] NULL
)
ALTER TABLE [sales_fact_20000101]
TE TABLE [dbo].[sales_fact_20000101] (
[date_key] [int] NOT NULL
CHECK ([date_key] BETWEEN 20000101 AND 20001231),
[product_key] [int] NOT NULL ,
[customer_key] [int] NOT NULL ,
[promotion_key] [int] NOT NULL ,
[store_key] [int] NOT NULL ,
[store_sales] [money] NULL ,
[store_cost] [money] NULL ,
[unit_sales] [float] NULL
)
ALTER TABLE [sales_fact_20000101]
可查询的分区视图
CHECK 约束强制使用的分区键
在成员表上定义的 UNION ALL 视图
查询性能：查询计划仅包括解析查询所必要的成员表。
加载性能：可高效地直接将数据批量加载至成员表。
存储：尽管推荐声明主键并在主键上创建索引的做法，但分区视图不要求主键索引。
视图最多可有 256 个成员表。
必须创建维护应用程序来管理分区和加载。
Microsoft 建议的做法是定义主键，并将事实表设计为本地（单个服务器上）的分区联合视图。大多数情况下，该定义会产生可更新的分区视图，但数据仓库维护应用程序应设计为直接将大多数数据批量加载至成员表（而不是通过视图进行）。
语法示例
以下代码示例用来说明定义成员表和联合视图以及将数据插入视图的语法：
-- 创建 1999 年事实表
CREATE TABLE [dbo].[sales_fact_19990101] (
[date_key] [int] NOT NULL
CHECK ([date_key] BETWEEN 19990101 AND 19991231),
[product_key] [int] NOT NULL ,
[customer_key] [int] NOT NULL ,
[promotion_key] [int] NOT NULL ,
[store_key] [int] NOT NULL ,
[store_sales] [money] NULL ,
[store_cost] [money] NULL ,
[unit_sales] [float] NULL
)
ALTER TABLE [sales_fact_19990101]
ADD PRIMARY KEY (
[date_key], [product_key], [customer_key], [promotion_key], [store_key])
;
-- 创建 2000 年事实表
CREATE TABLE [dbo].[sales_fact_20000101] (
[date_key] [int] NOT NULL
CHECK ([date_key] BETWEEN 20000101 AND 20001231),
[product_key] [int] NOT NULL ,
[customer_key] [int] NOT NULL ,
[promotion_key] [int] NOT NULL ,
[store_key] [int] NOT NULL ,
[store_sales] [money] NULL ,
[store_cost] [money] NULL ,
[unit_sales] [float] NULL
)
ALTER TABLE [sales_fact_20000101]
设计时要考虑的因素
矢量数据仓库围绕事实（标量）和矢量构建，从物理上通常表示为星形架构和雪花形架构，极少有同时包含事实和矢量的完全非正交化的平面表。典型情况下，矢量数据仓库的管理员仅对事实表进行分区；对矢量表进行分区几乎没有什么好处。在某些情况下，对包含多于一千万个成员的大型矢量表进行分区会有些好处。也可以对非矢量关系型数据仓库进行分区，本文中的一般观点仍然适用。
只有充分考虑系统体系结构和设计目标，才能制订有效的分区计划。即使使用相同的架构设计，仅用于填充服务分析多维数据集的关系型数据仓库可能采用一个不同于分析员直接查询的数据仓库的分区结构。带有滚动窗口的系统必须按时间分区，其他系统则不一定。
如果数据仓库包括分析服务多维数据集，Microsoft 建议关系型数据仓库和分析服务数据库中的分区应该为并行结构。维护应用程序被简化了：应用程序在关系型数据库中创建新表的同时创建一个新多维数据集分区。管理员仅需要掌握一种分区策略。不过，一个应用程序也可能有充分的理由对两个数据库以不同方式进行分区，唯一降低的将是数据库维护应用程序的复杂性。
分区设计概述
SQL Server 数据库中的分区表可以使用可更新或可查询（不可更新）的分区视图。在这两种情况下，表分区都是由每个分区都包含正确数据的 CHECK 约束来创建的。一个可更新的分区视图支持对视图进行 INSERT (或 UPDATE 或 DELETE）操作，并将操作推入至正确的基础表。这很有益处，但数据仓库应用程序通常需要进行批量加载，而这是无法通过视图执行的。下表总结了可更新和可查询分区视图的要求、优点和缺点。
要求 优点 缺点
可更新的分区视图
CHECK 约束强制使用的分区键
主键的分区键部分
无其他数据库限制的分区键部分
在成员表上定义的 UNION ALL 视图
查询性能：查询计划仅包括解析相关查询所需的成员表。
维护应用程序的简易性：数据可以被加载至 UNION ALL 视图，然后插入合适的成员表中
加载性能：通过视图加载数据的速度太慢，以至这种方式对大多数的数据仓库应用程序来说是不实用的。
灵活性：数据库设计对分区键可能要求额外的约束。
可查询的分区视图
CHECK 约束强制使用的分区键
在成员表上定义的 UNION ALL 视图
查分区设计概述
SQL Server 数据库中的分区表可以使用可更新或可查询（不可更新）的分区视图。在这两种情况下，表分区都是由每个分区都包含正确数据的 CHECK 约束来创建的。一个可更新的分区视图支持对视图进行 INSERT (或 UPDATE 或 DELETE）操作，并将操作推入至正确的基础表。这很有益处，但数据仓库应用程序通常需要进行批量加载，而这是无法通过视图执行的。下表总结了可更新和可查询分区视图的要求、优点和缺点。
要求 优点 缺点
可更新的分区视图
CHECK 约束强制使用的分区键
主键的分区键部分
无其他数据库限制的分区键部分
在成员表上定义的 UNION ALL 视图
查询性能：查询计划仅包括解析相关查询所需的成员表。
维护应用程序的简易性：数据可以被加载至 UNION ALL 视图，然后插入合适的成员表中
加载性能：通过视图加载数据的速度太慢，以至这种方式对大多数的数据仓库应用程序来说是不实用的。
灵活性：数据库设计对分区键可能要求额外的约束。
可查询的分区视图
CHECK 约束强制使用的分区键
在成员表上定义的 UNION ALL 视图
查询性能：查询计划仅包括解析查询所必要的成员表。
加载性能：可高效地直接将数据批量加载至成员表。
存储：尽管推荐声明主键并在主键上创建索引的做法，但分区视图不要求主键索引。
视图最多可有 256 个成员表。
必须创建维护应用程序来管理分区和加载。
Microsoft 建议的做法是定义主键，并将事实表设计为本地（单个服务器上）的分区联合视图。大多数情况下，该定义会产生可更新的分区视图，但数据仓库维护应用程序应设计为直接将大多数数据批量加载至成员表（而不是通过视图进行）。
询性能：查询计划仅包括解析查询所必要的成员表。
加载性能：可高效地直接将数据批量加载至成员表。
存储：尽管推荐声明主键并在主键上创建索引的做法，但分区视图不要求主键索引。
视图最多可有 256 个成员表。
必须创建维护应用程序来管理分区和加载。
Microsoft 建议的做法是定义主键，并将事实表设计为本地（单个服务器上）的分区联合视图。大多数情况下，该定义会产生可更新的分区视图，但数据仓库维护应用程序应设计为直接将大多数数据批量加载至成员表（而不是通过视图进行）。
查询速度
查询速度不应该作为对数据仓库关系型数据库进行分区的理由。对于分区和未分区的事实表，查询性能都差不多。在正确设计的分区数据库中，关系引擎仅在查询计划中包括解析查询所需的相关分区。例如，如果数据库按月分区，查询条件为 2000 年 1 月，则查询计划仅包括 2000 年 1 月的分区。结果查询将对分区表正确执行，与在分区键上带有簇索引的已索引合并表上执行的大体相同。
分区的缺点
复杂性
分区的主要缺点是需要管理员创建应用程序来管理分区。在尚未设计、测试和试运行应用程序来管理分区之前，将在关系型数据库中使用水平分区的数据仓库投入正式运行是不恰当的。本文的目的之一就是讨论与分区管理应用程序有关的问题和设计决策。
查询设计约束
要获得最佳的查询性能，所有的查询都应将条件直接放在事实表中的筛选键上。将约束放在第二张表（例如以日期为矢量的表）的查询将包括所有分区。
分区的优点
数据修剪
许多数据仓库管理员会定期将陈旧的数据归档。例如，一个单击流数据仓库可能只将详细数据联机保留三至四个月。其他常见的规则可能是联机保留 13 个月、37 个月或 10 年，当旧数据不在活动窗口中时就归档并从数据库中删除。这种滚动窗口结构是大数据仓库通常采取的做法。
在没有分区表的情况下，从数据库中删除旧数据的
进程需要一个很大的 DELETE 语句，例如：
DELETE FROM fact_table
WHERE date_key < 19990101
执行该语句开销会非常大，可能比同一张表的加载进程需要更多的时间。相反，对于分区表，管理员重新定义 UNION ALL 视图以排除最旧的表，然后将该表从数据库中删除（假设已确保备份该表），这个过程几乎可以在瞬间完成。
后面我们会讨论到，维护分区表的费用也很高。如果数据修剪是采用分区的唯一原因，设计者应考虑以数据分解的方式从未分区的表中删除旧数据。在低优先级进程上连续运行一个每次删除 1000 行（用“set rowcount 1000”命令）的脚本，直至删除所有希望删除的数据。该技术可在大系统上有效运用，比创建必要的分区管理系统更为直接。根据加载量和系统使用状况，该技术适合于某些系统，并应该考虑在系统上进行基准测试。
加载速度
加载数据最快的方法是将数据加载至空表或没有索引的表。通过加载至较小的分区表，渐变加载进程的效率将大大提高。
可维护性
一旦已建成支持分区的数据仓库分阶段应用程序，整个系统将变得容易维护。维护活动（包括加载数据、备份和还原表）可以并行地执行，这样可以极大地改善性能。渐变填充下行数据流多维数据集的进程可以被加速和简化。
数据仓库分区的优点：
大大缩短查询时间。
减少加载时间，改善数据库的可维护性。
解决从活动数据库中删除旧数据时出现的数据修剪问题。
该技术需要创建比非分区系统更复杂的数据分阶段应用程序。本文介绍
设计、实现和维护水平分区数据仓库的最佳方法。
因为有效的分区计划可以极大地改善查询性能，所以我们极力建议您对大型分析服务系统进行分区。尽管对于某些特定的数据仓库维护问题，对关系型数据仓库进行分区是有效的
解决方案，但通常不推荐您这样做。
在 SQL Server 2000 关系型数据仓库中使用分区
分区视图联接来自一组成员的水平分区数据，使数据看起来象来自同一张表。SQL Server 2000 区分本地分区视图和分布式分区视图。在本地分区视图中，所有相关表和视图驻留在 SQL Server 的同一实例上。在分布式分区视图中，相关表中至少有一张表驻留在其他某个（远程）
服务器上。建议您不要将分布式分区视图用于数据仓库应用程序。
矢量数据仓库围绕事实（标量）和矢量构建，从物理上通常表示为星形架构和雪花形架构，极少有同时包含事实和矢量的完全非正交化的平面表。由于矢量架构是最常见的关系型数据仓库结构，本文集中讨论这类架构的分区。下面的建议也适用于其他通用数据仓库架构。
摘要：本文介绍如何使用分区来改善
SQL Server 2000 Enterprise Edition 中
数据仓库的可管理性、查询性能和加载速度，并讨论关系型
数据库和分析服务多维数据集中的矢量架构的水平分区。
本文讨论数据仓库中数据分区的作用。关系型数据仓库和分析服务多维数据集都支持数据分区。分区的逻辑概念在 Microsoft® SQL Server™ 的两个引擎中是相同的：通过键（例如日期）对数据进行水平分区。在关系型数据库中，分区是通过创建单独的物理表（例如为每个月的数据创建一个表）并且定义一个成员表的联合视图来实现的。与此类似，SQL Server Enterprise Edition 中的分析服务支持显式的多维数据集分区。在关系型数据库和联机分析处理 (OLAP) 引擎中，物理存储的复杂性对于分析用户是不可见的。
4.1.2 适应技术环境的变化
技术环境的变化也是比较普遍出现的变化，比如业务系统的升级或迁移，可能对数据仓库的结构造成较大影响，分段存储区和基础数据仓库的使用，把这种风险降到最小。
分段存储区是业务数据进入数据仓库之前的缓存区，复杂的数据转换、清洗工作在分段存储区进入基础数据仓库时实现。当业务系统的数据结构发生变化时，可以利用从业务系统到分段存储区的数据抽取操作把这些变化与数据清洗转换操作隔离即在对新的业务系统进行数据抽取操作时，进行适当的数据结构转换，使分段存储区中的数据与原来保持一致，避免对数据仓库的数据结构和主要的后台处理程序造成影响。从业务系统到分段存储区的数据抽取程序只需十分简单的修改就可以实现需要的功能。
4.1.3 元数据管理的意义
元数据管理系统可以大大提高数据仓库系统适应变化的能力。元数据记录数据仓库过程中设计的业务规则、数据结构、数据移动规则等，一旦上述某一点发生变化，可以通过元数据管理工具，进行影响分析，定位需要修改的目
更多内容请看
数据仓库&BI 数据仓库构建专题，或
进入讨论组讨论。
4.1.1 适应业务需求的变化
用户需求的变化根据变化的程度和对数据仓库系统的影响被分为两个不同的层次，
—— 可自适应的变化
即信息的需求虽然有所变化，但利用已经存储在数据集市中的数据仍然可以支持，需要改变的只是数据访问和信息展现的方式，这不需要对数据仓库的数据结构进行修改就可以实现，在进行数据模型设计时，在保证查询效率的前提下，要尽量使各个业务主题可以满足最多的信息需求。
—— 需要调整的变化
即数据集市的数据虽然无法满足信息的需求，但可以从基础数据仓库中的数据获得，针对这样的变化有两种处理方法，
• 如果这个变化只是偶尔出现，可以直接从基础数据仓库的数据中进行数据的查询和分析，这样可能会牺牲一些性能，但不需对数据仓库的结构和数据模型进行修改
• 另一种方法是针对以后将频繁使用的新业务需求，可以采取修改现行数据集市和建立新的数据集市的方法实现，由于数据集市只是对基础数据仓库中相关的详细数据进行聚合，所以只需要很小的工作量就可以调整数据仓库实现新的需求。
四、发展与扩充
数据仓库数据模型的设计在满足目前业务需求的基础上，必须考虑未来的业务情况和需求，需要认真考虑两方面的问题，
• 适应未来业务需求和技术环境的改变
• 数据仓库本身涉及业务范围的扩展
4.1 适应未来的变化
分段式数据仓库结构可以大大提升数据仓库适应变化的能力。在未来可能对数据仓库产生影响的变化无外乎两种，
• 业务需求的变化引致对信息需求的变化
• 技术环境的变化
—— 独立业务分析
财产保险各业务、各险种的业务特点具有极大差异，对不同险种业务人员所关心的信息也不尽相同，所以各个业务在独立业务分析模块构成不同的分析主题；除此之外对有共性的业务进行综合构成综合的业务分析主题，比如个人大客户分析、企业客户业务分析就是把相关的业务主题进行综合的结果。
—— 综合业务分析
综合业务分析主要面向保险公司整体业务的分析，从综合业务分析可以了解保险公司的用户构成情况、中介发展情况、业务收入情况、赔付情况、共保/分保、客户服务、保费收入情况和竞争对手发展情况，从综合业务模块可以了解各个业务的总体发展情况，但由于各个业务属性的差异，详细的业务分析必须进入独立业务分析模块。
按照数据粒度划分的数据集市结构
轻度汇总数据可以支持很多对客户个体的业务分析，比如从基础数据仓库投保记录汇总生成每个用户一段时间的投保情况；中度汇总数据在业务分析中经常被用到，大多数情况用于对宏观客户群体的业务分析，比如制定保费政策时，可以通过中度汇总数据了解不同险种不同时间的发展和收益情况；高度汇总数据用于了解保险公司业务整体的运营和发展情况。在实际的设计中，可以根据用户需求决定针对不同的业务采用不同的数据粒度。
3.2.2.2 按照业务划分
按照业务进行数据集市结构的划分，可以把数据集市从总体上分为两个模块，综合业务分析模块和独立业务分析模块，如下图，
3.2.2 数据集市
详细业务数据是数据仓库的基础，但对于金融企业来说，对业务发展宏观情况的把握是比详细的客户分析更为迫切的需求。所以在初期任何金融行业数据仓库的应用都以对聚合数据的分析为主。聚合数据存储在数据集市中，数据集市的数据直接通过查询工具提供给最终用户，所以数据集市的设计直接关系到数据仓库应用的成败。现阶段，我国大多数金融数据仓库系统正处于初始阶段，其主要功能需求是了解各省分公司、子公司和各项业务的发展和运营情况，因此数据集市的设计是数据模型设计最重要的环节。数据集市的
数据结构可以按照数据粒度和数据所体现的业务范围划分。
3.2.2.1 按照数据粒度划分
数据集市按照数据粒度的大小可以划分为三个部分，轻度汇总、中度汇总、高度汇总，汇总程度越高，数据粒度越大，数据在线保留时间越长，所体现的业务事实越宏观，如下图所示，
—— 客户退保/退费记录
了解用户退保和退费的情况，每一笔退保/退费的原因、时间、保单号、金额等等
—— 中介信息
描述中介公司的类型，比如经纪人、兼职代理人或专业代理人，各中介公司的业务量、保险公司之处的中介费用等等。
3.2.1.2 基础数据仓库概念模型的实现
概念模型的意义在于体现用户的需求和基本的数据组织结构，在实际的设计过程中，可能需要根据实际的业务情况进行模型的拆分。比如客户资料模型，针对不同客户的情况拆分成企业客户、个人客户、集团个人客户；投保记录模型，根据不同的业务拆分成车险投保记录、财产险投保记录、运输险投保记录、船舶险投保记录等，
—— 客户索赔记录
客户索赔记录是过去客户每次索赔的详细记录，比如索赔金额、时间、保单号、立案号、险种、索赔清单、索赔单证、事故描述等，索赔记录是客户行为模式的重要组成，也是反欺诈分析、客户流失分析的重要依据。
—— 客户赔付记录
记录保险公司对每一个客户的每一笔赔付，主要的信息包括赔付时间、立案号、赔案号、单证、赔付计算情况、损失原因、赔付金额、是否通融赔付、通融赔付的原因和通融赔付金额等，与索赔记录相结合，可以了解保险公司对客户索赔的反应时间和处理速度
—— 客户投保记录
以详细的保单数据为主，体现在某一时间段内客户的投保情况。由于数据量比较庞大，客户投保记录一般在数据仓库中在线保存两年，最长不超过五年。投保记录是业务分析最重要的数据基础，必要的时候，投保记录可以为很多业务提供数据支持，比如大客户管理等。
—— 客户缴费记录
记录用户投保后保费的缴纳情况，从中可以了解保险公司与每一个客户在不同业务的应收情况。是对业务发展的重要衡量依据，也是对客户群进行细分的重要指标。不同保险企业对缴费记录在线保存的时限要求不同，一般在一年以上，五年以下。
国内财产保险经营的主要保险业务如下，
• 机动车辆保险
• 家庭财产保险
• 企业财产保险
• 建筑安装工程保险
• 货物运输保险
• 船舶保险
• 航空航天保险
• 其它保险
3.2 数据仓库概念模型
目前保费收入还是国内财产保险企业的主要利润来源，在激烈的市场竞争中客户是竞争的焦点，在数据仓库中客户信息占有极为重要的地位；围绕着客户资料信息，客户的投保记录、索赔记录都具有极高的分析价值；另外合作伙伴对保险业务的开拓也具有重要地位，如保险代理人、经纪人等中介公司的相关信息。
3.2.1 基础数据仓库
基础数据仓库用以存储详细的业务数据，采取以客户信息为中心，各个业务环节数据为基础的中心-发散型结构，系统面向经营分析，以经营业务数据为主，如下图所示，
3.2.1.1 基础数据仓库概念模型介绍
—— 客户资料
负责存储用户的详细资料，主要的客户属性包括，客户ID、用户第一次投保时间、资料更新时间、业务类型、用户特征属性、用户类型、缴费情况、投保情况、信用情况、保费收入水平等等。客户资料主题的数据主要针对企业用户和大客户，在可能的情况下，尽量体现客户间的关系，比如某一家庭财险用户隶属于某一企业客户。客户资料数据体现最新的客户状态。客户资料永久在线保存，当客户资料发生变化时，旧的客户信息被转移到客户历史资料库中。在每一个客户的生命周期中，客户资料随时可能发生变化，客户历史资料数据详尽的记录每一次变化的细节，为以后客户信用评估和用户行为分析需求提供依据，客户历史资料永久在线保存。
2.3 数据集市（Data Mart）
根据业务需求将数据仓库数据分类成几个不同的数据集市，每个数据集市完成不同的分析和查询需求，数据集市中的数据通常由基础数据仓库的详细数据聚合而来，根据数据聚合程度的不同包含轻度聚合、中度聚合和高度聚合三种不同的层次。汇总的方式将依据数据量的大小和使用频度综合考虑。
更多内容请看
数据仓库&BI 数据仓库构建专题，或
进入讨论组讨论。
三、概念模型
数据模型
设计的第一步是对用户需求的归纳，需要综合考虑业务划分和用户组织两方面的问题，在明确需求的基础上，可以进行逻辑数据模型的设计，大致需要经过分为三个步骤，高层模型设计即概念模型设计，确定
数据仓库的主要主题及相互关系；中层模型设计明确各主题域的实体；底层模型设计明确各个实体的属性。本章以国内某财产保险公司的业务为例介绍财产保险行业的数据仓库建模。
数据仓库数据模型的技术功能划分
2.1 分段存储区（Staging Area）
由于数据仓库中的数据结构和组织方式具有很大差异、所有原始业务系统的数据必须经过严格的抽取、映射和转换，数据的整合过程十分复杂，通常会耗费比较长的处理时间。如果从业务系统直接抽取数据到数据仓库，必定会占用许多业务系统的资源和时间，为了避免影响业务系统的运行，我们在数据模型的设计中引入分段存储区的概念。
分段存储区（Staging Area）是为了保证数据移动的顺利进行而开设的阶段性数据存储空间，它是业务系统原始数据进入数据仓库前的缓存区。需要进入数据仓库的各个业务系统的数据首先直接快速传输到分段存储区，再从分段存储区经过清洗、转换、映射等复杂的数据移动处理转移到目标数据仓库中。从业务系统到分段存储区的数据传输，应尽量避免进行复杂的数据处理，以保证数据的快速导入而尽量减小对业务系统造成的压力。分段存储区的数据有关系
数据库和文件两种不同存储方式，分别对应于不同运营系统的数据源。数据成功导入数据仓库之后，应清空分段存储区中的数据。
在数据仓库系统的运行和使用过程中，分段存储区的作用主要体现在以下几个方面，
• 可以减少对业务系统资源的占用，避免复杂数据转换对业务系统的影响
• 根据经验，跨越网络特别是广域网络的数据库操作会大大降低数据处理的效率，而且处理的复杂程度越高，网络对处理效率的影响越严重，分段存储区可以大大加速数据仓库后台数据数据处理过程的实现；
• 分段存储区作为数据缓存区，可以在一定程度上屏蔽业务系统变化对数据移动整合系统的影响
• 如果在数据处理过程中发生系统故障，作为数据仓库系统的备份数据，可以直接从分段存储区进行数据仓库
数据恢复，而不必要再从业务系统原始数据开始。
2.2 基础数据仓库（BaseLine）
基础数据仓库存储所有最详细的业务数据。该层数据直接来源于对分段存储区数据的清洗和加工，属于未经汇总的数据，但数据的组织方式可能已经完全不同于原始的业务系统。根据业务需求的不同，基础数据仓库的组织形式以三范式模型为主，在有的系统中也可能采用星型或雪花模型。
通常在金融企业的数据仓库系统中，基础数据仓库数据包括未经汇总的客户交易数据，用户资料数据、客户服务数据等，此外一些相关数据如网络利用，竞争对手，成本投资数据也包括在内。由于基础数据仓库数据是对原始业务数据的原形再现，所以数据量会非常庞大，根据不同业务的需要数据保留的时间在6个月到两年不等。
—— 考虑未来的可扩展性
数据仓库系统是一个与企业同步发展的有机体，数据模型作为数据仓库的灵魂必须提供可扩展的能力，在进行数据模型设计时必须考虑未来的发展，更多的非核心业务数据如人事数据、市场数据、竞争对手数据等必须可以方便的加入到数据仓库，而不需要对数据仓库中原有的系统进行大规模的修改。
二、数据模型的技术功能结构化分
大规模的数据仓库系统特别是金融行业数据仓库的
数据结构从技术角度划分应当包含三个部分，如下图所示，
—— 兼顾效率与数据粒度的需要
数据粒度和查询效率从来都是矛盾的，细小的数据粒度可以保证信息访问的灵活性，但同时却降低了查询的效率并占用大量的存储空间，数据模型的设计必须在这矛盾的两者中取得平衡，优秀的数据模型设计既可以提供足够详细的数据支持又能够保证查询的效率。
—— 支持需求的变化
用户的信息需求随着市场的变化而变化，所以需求的变化只有在市场竞争停顿的时候才会停止，而且随着竞争的激化，需求变化会越来越频繁。数据模型的设计必须考虑如何适应和满足需求的变化。
—— 避免对业务运营系统造成影响
金融企业的数据仓库系统是一个每天都在长大的庞然大物，它的运行很容易占用很多的资源，比如网络资源、系统资源，在进行数据模型设计的时候也需要考虑如何减少对业务系统性能的影响。
金融企业的信息系统具有业务复杂、机构复杂、系统庞大的特点，因此金融行业数据仓库建模必须注意以下几个方面，
—— 满足不同用户的需求
金融行业的业务流程十分复杂，数据仓库系统涉及的业务用户众多，在进行数据模型
设计的时候必须兼顾不同业务产品、不同业务部门、不同层次、不同级别用户的信息需求。
数据仓库应该支持企业的各种业务，比如对财产保险行业应该考虑财产险、货物运输险、工程险、责任险等不同业务的特点；不同的业务部门对信息的需求各有不同，应考虑业务、市场、财务、管理等各个部门的需要；不同层次的组织所关心的信息不同，数据模型应支持地市公司、省公司和总公司的信息需求；金融企业是知识密集型的企业，知识密集型企业的显著特征是智能员工(Knowledge Worker)占企业员工的大多数，数据仓库必须支持所有相关智能型员工的信息需求，包括高层领导、基层领导和普通员工。
一、
数据仓库建模的原则
模型是对现实事物的反映和抽象，它可以帮助我们更加清晰的了解客观世界。数据仓库建模在业务需求分析之后开始，是数据仓库构造工作正式开始的第一步，正确而完备的数据模型是用户业务需求的体现，是数据仓库项目成功与否最重要的技术因素。
现在，数据仓库已经建立成功，下一步就是在OLAP服务器上建立元数据数据库。这个数据库和我们以前所说的数据库不同，他是存放元数据的数据库，比如我们下一步要创建的多维数据集、角色、数据源、共享维度和挖掘模型等。然后需要和早期在 ODBC 数据源管理器中建立的数据源连接，使其与数据仓库连接上。这些工作做好了之后，就可以用数据仓库中的维表来建立共享维度，现在以时间维和地址维为例。其创建过程一样。依此点下一步即可创建时间维（TIME），下面用ADDRESS和DETAIL建立雪花模型共享维度,点下一步即可创建DETAIL维。创建完成之后都要进行处理才能生效。维度创建好了之后就该创建多维数据集了。多维数据集是一种基于维表和事实表的数据集，以他来对数据仓库进行快速的访问。我们的多维数据集结构如下：
DETAIL（SREET）
DETAIL（MARK）
ADDRESS（PROVINCE，CITY）
TIME（YEAR，DAY）
到现在一个简单的数据仓库架构已经建立成功，我们利用前端分析工具来对建立的数据仓库做查询，看能否实现我们的简单的业务要求，先以Excel作为查询工具。我们除了用Excel，ENGLISH QUERY 等现成工具做查询外，还可以用MDX函数直接对OLAP做查询。
到现在为止，一个简单的数据仓库已经创建成功，可以实现一些简单的业务查询。这个实例主要是分析数据仓库的创建过程以及进一步加深对数据仓库的认识和了解，进一步理解其中的基本概念。
在这一阶段要做好很多前期的工作，因为你的原始数据库中的数据也许和你的正要建立的数据仓库的需求也许有很大的出入，结构完全是两马事。你如何才能将你的原始数据提取出来，作为数据仓库的有用数据呢，你的原始数据库中存储的是零碎的事务数据，而你的数据仓库中要的是经过转化和提炼过的统计数据，比如说，你的原始数据库中存储这每天的所有存款和取款记录，而你的数据仓库并不关心你的每条记录的数据，而是希望在最短的时间内，以最快的速度统计出这个月的所有存款和取款的总数量，如果这种查询放在原来的数据库上来做的话，也就失去了数据仓库的意义，超大规模的数据使你无法查询下去，这时候你就要将对这个查询有意义的数据转化到数据仓库，这就是数据清洗，即ETL。实现数据清洗有很多的方法，也有很多的细节问题，比如，数据类型的匹配，数据格式的转换，异地数据表数据集中到一起时有主键重复，以及你如何定期，按时的将数据加工到数据仓库中来等等。在我的示例中没有严格的经过着一步，因为我没有规范的原始数据库，也没有规范的业务需求。我只是运用星型模型和雪花模型做了几个典型的数据仓库表。其表关系如下：
窗口中FACT为事实表，TIME，ADDRESS，DETAIL分别为时间维，地址维，详细地址维，DETAIL又是ADDRESS的子维。他们又构成雪花模型。其中都有部分数据。
15、数据挖掘模型：数据挖掘使您得以定义包含分组和预测规则的模型，以便应用于关系数据库或多维 OLAP 数据集中的数据。之后，这些预测模型便可用于自动执行复杂的数据分析，以找出帮助识别新机会并选择有获胜把握的机会的趋势。
实例构建过程与分析
1、现在以一个比较简单的实例来分析和探讨MS SQL Server 数据仓库的构建过程。实际上数据仓的构建是相当复杂的，他结合了数据仓库的前端技术和很强的业务要求。在这儿只是以一个简单的实例来说明他大致的构建流程。
2、构建数据仓库模型，他包括两部分，一是要考虑原来的数据源能够提供哪些有用的数据，也就是经过数据的筛选之后能够为数据仓库所用。二是要看公司业务层需要什么样的分析结果。这要和公司的高级决策层紧密配合，完全了解他的业务需求，因为数据仓库的使用者主要是公司的高级决策者。
12、切块：由多个维的多个成员限定的分区数据，称为一个切块。
13、切片：由一个维的一个成员限定的分区数据，称为一个切片。
14、数据钻取：最终用户从常规多维数据集、虚拟多维数据集或链接多维数据集中选择单个单元，并从该单元的源数据中检索结果集以获得更详细的信息，这个操作过程就是数据钻取。
9、混合 OLAP (HOLAP)：HOLAP 存储模式结合了 MOLAP 和 ROLAP 二者的特性。
10、粒度：数据汇总的层次或深度。
11、聚合|聚集：聚合是预先计算好的数据汇总，由于在问题提出之前已经准备了答案，聚合可以改进查询响应时间。
6、数据挖掘：数据挖掘使您得以定义包含分组和预测规则的模型，以便应用于关系数据库或多维 OLAP 数据集中的数据。之后，这些预测模型便可用于自动执行复杂的数据分析，以找出帮助识别新机会并选择有获胜把握的机会的趋势。
7、多维 OLAP (MOLAP)：MOLAP 存储模式使得分区的聚合和其源数据的复本以多维结构存储在分析
服务器计算机上。根据分区聚合的百分比和
设计，MOLAP 存储模式为达到最快查询响应时间提供了潜在可能性。总而言之，MOLAP 更加适合于频繁使用的多维数据集中的分区和对快速查询响应的需要。
8、关系 OLAP (ROLAP)：ROLAP 存储模式使得分区的聚合存储在关系数据库的表（在分区数据源中指定）中。但是，可为分区数据使用 ROLAP 存储模式，而不在关系数据库中创建聚合。
4、元数据：不同 OLAP 组件中的数据和应用程序的结构模型。元数据描述 OLTP
数据库中的表、数据仓库和数据集市中的多维数据集这类对象，还记录哪些应用程序引用不同的记录块。
5、级别：级别是维度层次结构的一个元素。级别描述了数据的层次结构，从数据的最高（汇总程度最大）级别直到最低（最详细）级别。
基本概念：
1、多维数据集：多维数据集是联机分析处理 (OLAP) 中的主要对象，是一项可对数据仓库中的数据进行快速访问的技术。多维数据集是一个数据集合，通常从数据仓库的子集构造，并组织和汇总成一个由一组维度和度量值定义的多维结构。
、维度：是多维数据集的结构性特性。它们是事实数据表中用来描述数据的分类的有组织层次结构（级别）。这些分类和级别描述了一些相似的成员集合，用户将基于这些成员集合进行分析。
3、度量值：在多维数据集中，度量值是一组值，这些值基于多维数据集的事实数据表中的一列，而且通常为数字。此外，度量值是所分析的多维数据集的中心值。即，度量值是最终用户浏览多维数据集时重点查看的数字数据。您所选择的度量值取决于最终用户所请求的信息类型。一些常见的度量值有 sales、cost、expenditures 和 production count 等。
异构的数据源是大部分企业所面临的问题，数据集成，也就是在整合数据孤岛的同时，合并、净化和标准化数据成为企业数据管理领域面临的最主要问题之一。
通过SQL语句访问远程或异构数据库是集成数据的一种方式。除此之外，还包括以下几种方式：自定义接口将信息从一个应用程序传到另一个应用，这能够按照用户需求而精确实现，但创建和维护费用很大；数据库复制，很多产品提供能定期或持续地将整个数据库或数据库的一部分拷贝到另一个地点，复制非常简单，但除了拷贝之外没有处理数据的其他能力；ETL本身是用于创建数据仓库和数据集市，能够将数据从一个位置移到另外位置，并应用规则或表查询功能以某种方式连接或转换数据，ETL功能很强大但非常复杂；Web服务，包括XML标准在内的Internet协议所驱动的方式，用于完成独立的两个系统之间的数据交换，Web服务允许基于SQL的关系数据被作为XML数据来访问，也允许通过SQL访问本地XML，当应用之间是松耦合或无法用其他方式实现集成时非常有用。
当然，数据集成可以采用其中一种方式或以上多种方式进行组合。对于用户来说，不管采用何种方式集成数据，都面临很大的挑战，在整个过程中要非常谨慎地创建应用和数据之间的接口，以保障信息的精确度并满足不同终端用户的需求。
商业智能系统的分析展现是技术发展较为活跃的部分。OLAP及其他商业智能的应用以Web服务形式提供，并与企业电子商务门户集成。OLAP和商业智能应用的前端的界面转化成瘦客户端的应用模式(浏览器、Intranet模式)已成为普及性的要求。以XML形式发放商业智能应用的分析结果是新的发展趋势。
数据挖掘的模块、算法和工具将更多地融合到OLAP组件甚至数据仓库服务器系统中。同时，商业智能应用与企业门户、企业应用集成紧密相连。新的商业智能系统不再是一个孤立的应用，它与企业中的其他应用系统将紧密集成。
从商业智能应用来看，目前的发展是呈行业化和专业化。首先，商业智能系统将更具行业化的特点。笼统的商业智能系统渐渐成为概念，客户实际需要的系统则分为银行、保险、制造业、电信等各种领域。并且，每个行业有其关注的重点和分析的模型。
其次，商业智能应用更加强调应用的集成。主要应用领域包括：分析型的CRM，客户关系管理和优化仍将是商业智能应用很重要的一块; 服务于ERP系统的商业智能，传统的ERP厂商都在将商业智能应用或模块加入到他们的ERP系统中;与SCM 集成的供应链管理优化。
数据库发展到今天只是比较好地解决了自然界中结构化数据的管理问题。对占据所有数据量85%的半结构化和非结构化数据如何管理的问题还在摸索之中。那什么是非结构化数据呢？不能被映射成关系模型的自然界数据通常就是非结构化数据，如常见的报纸、传真、声音、图形、图像数据都是非结构化数据。
在过去的十年内，我们曾经看到过纯对象数据库、面向对象的关系型数据库、数字图书馆、多媒体文档管理系统等等各种尝试，但到目前为止我们还没有一种解决方法能像数据库对结构化数据那样容易的进行存储、查询、分发和维护等操作。尤其是查询操作，针对声音、图形、图像等数据的检索，目前的系统是那么无力。只能根据一些有限的索引或标志信息来操作，与对关系型数据所提供的检索手段相比，真有天壤之别。
以数据仓库为基础的商业智能应用正在被很多大型行业提到议事日程上。从技术来看，商业智能在各环节的发展走向如下。
在ETL（抽取、转化和装载）环节，对多种数据源的访问，包括非关系型数据库和大型主机，成为基本的技术指标。数据抽取系统将会把XML纳入数据采集格式的范围; 在数据分析上，越来越多的企业和机构要求其决策分析环境能够提供更为接近实时的数据分析，技术手段主要集中在ETL环节，交易日志的监控、数据的复制成为数据采集的手段。
今天，并行处理加决策支持优化的关系数据库系统仍是数据仓库领域的主角。大家普遍认为发展方向是在关系数据库基础上融合决策支持和事务处理的能力，不过这样的策略或许仍存有争议，毕竟有不少技术人员认为事务处理和决策分析对关系数据库来说有如鱼和熊掌，不能兼得。尽管如此，在关系数据库中加入OLAP（联机分析处理）能力、SQL语句中加入数据统计公式和算法正在被各厂商提供的产品中实施。
传统
数据库应用的不断成熟促使用户和厂商都在寻找如何充分利用历史数据的途径。我们也可以非常清晰地看到以下三个技术和应用热点全部都是围绕着这个目的而出现的。
数据库发展到今天只是比较好地解决了自然界中结构化数据的管理问题。对占据所有数据量85%的半结构化和非结构化数据如何管理的问题还在摸索之中。那什么是非结构化数据呢？不能被映射成关系模型的自然界数据通常就是非结构化数据，如常见的报纸、传真、声音、图形、图像数据都是非结构化数据。
在过去的十年内，我们曾经看到过纯对象数据库、面向对象的关系型数据库、数字图书馆、多媒体文档管理系统等等各种尝试，但到目前为止我们还没有一种解决方法能像数据库对结构化数据那样容易的进行存储、查询、分发和维护等操作。尤其是查询操作，针对声音、图形、图像等数据的检索，目前的系统是那么无力。只能根据一些有限的索引或标志信息来操作，与对关系型数据所提供的检索手段相比，真有天壤之别。
前段时间在做一个挖掘模型时，模型的特征决定了选择的数据是严重有偏的，怎样在这样的数据上进行抽样，得到能比较好地反映真实情况的数据样本是很关键的。自己对统计学仅仅限于大学课程的学习，很少做过实验，在做数据预处理走了一些弯路。下面对数据挖掘中的抽样发表一点浅见。谢谢苦瓜兄弟解答，希望和大家多多交流：）
在数据挖掘的数据预处理过程中，宽表数据往往是几十万，上百万级记录的。要对所有数据进行训练，时间上很难满足要求，因此对数据进行抽样就很必要了，不同的数据抽样方法对训练结果模型的精度有很大影响。可以考虑用一些数据浏览工具，统计工具对数据分布做一定的探索，在对数据做充分的了解后，再考虑采用合适的数据抽样方法，抽取样本数据进行建模实验。对一般的模型，比如客户细分，主要是数据的聚类，我在做抽样时用了随机抽样，也可以考虑整群抽样；而做离网预警模型或者金融欺诈预测模型时，数据分布是严重有偏的，而且这种有偏数据对这类模型来说恰恰是至关重要的。一般采用分层抽样和过度抽样结合有不错的效果，分层抽样和过度抽样的区别自己也不是很了解，现在只能是做个概述了。
几种常用的抽样方法：
1.简单随机抽样（simple random sampling）
将所有调查总体编号，再用抽签法或随机数字表随机抽取部分观察数据组成样本。
优点：操作简单，均数、率及相应的标准误计算简单。
缺点：总体较大时，难以一一编号。
2.系统抽样（systematic sampling）
又称机械抽样、等距抽样，即先将总体的观察单位按某一顺序号分成n个部分，再从第一部分随机抽取第k号观察单位，依次用相等间距从每一部分各抽取一个观察单位组成样本。
优点：易于理解、简便易行。
缺点：总体有周期或增减趋势时，易产生偏性。
3.整群抽样(cluster sampling)
先将总体依照一种或几种特征分为几个子总体（类．群），每一个子总体称为一层，然后从每一层中随机抽取一个子样本，将它们合在一起，即为总体的样本，称为分层样本
优点：便于组织、节省经费。
缺点：抽样误差大于单纯随机抽样。
4.分层抽样（stratified sampling）
将总体样本按其属性特征分成若干类型或层，然后在类型或层中随机抽取样本单位，合起来组成样本。有按比例分配和最优分配（过度抽样是否就是最优分配方法？）两种方案。
特点：由于通过划类分层，增大了各类型中单位间的共同性，容易抽出具有代表性的调查样本。该方法适用于总体情况复杂，各类别之间差异较大（比如金融客户风险/非风险样本的差异），类别较多的情况。
优点：样本代表性好，抽样误差减少。
六、检查ODM安装
oracle9i数据挖掘使数据库一个选项，如果你安装了，那么通过下面语句会返回TRUE:
SELECT VALUE FROM V$OPTION WHERE PARAMETER=’ORACLE DATA MINING’;
这个查询一般由DBA登录执行，如SYSTEM/MANAGER。
七、必须协调的属性集
八、启动和停止ODM任务监控器
启动：EXEC DM_START_MONITOR;
停止：EXEC DM_STOP_MONITOR;
九、ODM错误信息
当执行ODM方法使，在PL/SQL层或JAVA 层可能会发生错误，由两个表会包含错误的信息：
ODM_MESSAGE_LOG ：java层的错误信息；
ODM_ERROR_TABLE ：PL/SQL层的错误信息。
四、管理：
1、 提升性能：
提升ODM的性能，使能并行，要设置数据库初始化参数：PARALLEL_MAX_SERVERS和PARALLEL_MIN_SERVERS基于你的系统熟悉。
2、 改变默认的ODM密码：
和改变其他数据库密码一样。
3、 ODM API文档：
在$ORACLE_HOME/DM/DOC/ODMJDOC.TAR，解压并阅读。
4、 ODM配置参数：
下面的ODM配置参数在ODM_CONFIGURATION表里。这些参数可能要修改因为你的环境：
ABN_ALG_SETTING_NF_DEFTH
类型使int；默认使10。指定最大刻度为任何一个网络特性ABN设置（Specifies the maximum depth of any Network Feature for ABN setting.）。
ABN_ALG_SETTING_NUM_NF
类型使int；默认使10。指定最大刻度为任何一个网络特性ABN设置（Specifies the maximum depth of any Network Feature for ABN setting.）。
ABN_ALG_SETTING_NUM_PRUNED_NF
略
五、提高ODM聚类的速度
你能加速这些包通过编译他们到本地代码在共享库里。程序被转换成c代码，用你的C编辑器编译他们并联到oracle进程。详细信息怎么编译PL/SQL程序到本地代码，看PL/SQL user‘s guide and reference。
二、简要
ODM应用程序在数据库执行数据挖掘。通过基于java的API，所有的建模和评分功能都易于理解和使用。Oracle数据库为应用开发者开发综合应用提供基础，和完整的标题控制（programmatic control）的数据挖掘功能去在数据库里进行数据挖掘。
三、安装
一个详细的安装总览和详细的安装步骤。
1、 ODM需求：
ODM是oracle9i企业版的一个选项
ODM的一般软件需求：Java1.31_01；需要的java.sql包包含在JDK1.2
2、 如果你计划ODM在RAC上运行，那么ODM 的表空间至少为250M。
3、 安装ODM时的三种情况：oracle9i和ODM都没有安装过；oracle9i或之前的版本已经安装；oracle9i的第2版已经安装。
3.1、oracle9i没有安装：
如果你安装ODM的系统上没有数据库，有两种方式去安装ORACLE9I:
创建数据库使用（seed datadase）；
创建数据库但是不用安装软件，就是说创建用（custom database）
（1） ODM安装用一个seed数据库：
启动OUIà创建一般用途数据库à当安装成功完成时，将ODM和ODM_MTR帐户解锁并修改密码，用以下命令：
alter user odm identified by new_ODM_password account unlock
alter user odm_mtr identified bu new_MTR_password account unlock
以ODM用户登录并启动ODM Monitor，用以下命令启动：
exec DM_START_MONITOR
安装成功后，ODM软件位于$ORACLE_HOME/DM DRIECTORY.
（2） ODM安装与一个CUSTOM DATABASE：
创建一个自定义数据库要比创建一个预定义的数据库时间长，但他能使你去指定和改变数据库参数。
步骤：创建一个自定义的数据库à运行oracle database configuration assistant（DBCA）à选取ODM选项à以ODM用户登录并启动ODM Monitor，用以下命令启动：exec DM_START_MONITOR。
（3） Oracle9i或之前的版本已经安装：
升级到oracle9i第二版。如果ODM9.0.1已经安装了，他升级到ODM第二版当你的数据库升级时。
如果ODM没有安装，安装并配置ODM第二版。
（4） ODM数据库参数：
在预定义的数据库（seed database）默认的初始化参数一般都满足运行ODM，如果你创建一个自定义的数据库，那么下面的参数设置可能用做一般的数据库方针。ODM指定的参数必须被正确的显示。我们推荐你协调其它参数基于你的硬件资源等：
###########################################
# Cache and I/O
###########################################
db_block_size=8192
db_cache_size=67108864
db_file_multiblock_read_count=16
###########################################
# Cursors and Library Cache
###########################################
open_cursors=300
###########################################
# Miscellaneous
###########################################
compatible=9.2.0.0.0
###########################################
# Pools
###########################################
java_pool_size=67108864
large_pool_size=10M
shared_pool_size=67108864
###########################################
# Optimizer
###########################################
hash_join_enabled=TRUE
###########################################
# Processes and Sessions
###########################################
processes=150
###########################################
# Sort, Hash Joins, Bitmap Indexes
###########################################
sort_area_size=5242880
sort_area_retained_size=2097152
###########################################
# ODM Specific
###########################################
aq_tm_processes = 1
job_queue_processes =10
###########################################
# Parallel setting, adjust according to CPU number
###########################################
parallel_max_servers = 32
parallel_min_servers = 2
（5） ODM安装在Real Application Cluster
ODM安装到RAC和安装到非RAC系统上是相似的，如果你用安装程序去创建一个预定义的数据在集群上，ODM会被安装到这个数据库上就像在非RAC环境下。
如果你选择创建一个自定义数据库在你的RAC上并安装ODM，我们建议你配置ODM表空间至少250M（we recommend that you configure the ODM tablespace with a rawdevice partition of at least 250 MB.）。
（6） 升级ODM:
ODM升级是数据库升级的一部分，当数据库升级时ODM自动升级。
升级包括两部分：ODM schema upgrade和ODM Java object upgrade。
ODM Schema Upgrade：
一、介绍
文档中描述怎样去安装oracle9i的数据挖掘（ODM）软件和在UNIX和Windows平台上执行ODM里的其他管理功能。
1、这个文档是为那些计划安装ODM的数据库管理员或系统管理员编写的。
2、包含以下内容：
总括：简要的描述Oracle 9i Data Mining的二版；
安装：描述一般安装的步骤；
管理：描述管理员的任务，包括提高ODM的性能、开始和结束ODM的任务管理器、错误监视等。