2008年3月25日星期二

Seam学习笔记---Seam的组件

Seam组件

无状态Session Bean


无状态Session Bean组件无法在多次调用之间保持状态。因此,它们通常在不同的Seam上下文中,操作其他组件的状态。他们可以作为JSF的action listener,但是不能为JSF组件的显示提供属性。

无状态Session Bean总是生活在无状态上下文中。

无状态Session Bean是Seam组件中最没趣的了。

Seam无状态Session Bean组件可以使用 Component.getInstance() 或者 @In(create=true) 实例化。它们不能直接使用JNDI或者 new 操作实例化。

有状态Session Bean


有状态Session Bean不仅可以在bean的多次调用之间保持状态,而且在多次请求之间也可以保持状态。 不由数据库保存的状态通常应该由有状态Session Bean保持。这是Seam和其他web框架之间的一个显著的不同点。 其他框架把当前会话的信息直接保存在 HttpSession 中,而在Seam中你应该把它们保存在有状态Session Bean的实例中,该实例被绑定到会话上下文。这可以让Seam来替你管理状态的声明周期,并且保证在多个不同的并发会话中没有状态冲突。

有状态Session Bean经常被作为JSF action listener使用,也可以作为JSF显示或者form提交的后台bean,提供属性供组件访问。

默认情况下,有状态Session Bean会被绑定到Conversation Context。它们绝不会绑定到page或stateless context。

对Session范围的有状态Session Bean的并发请求,会被Seam按顺序串行处理。

Seam有状态Session Bean组件可以使用 Component.getInstance() 或者 @In(create=true) 实例化。它们不能直接使用JNDI或者 new 操作实例化。

实体Bean


实体Bean可以被绑定到上下文变量,起到Seam组件的作用。因为Entity除了上下文标识之外,还有持久标识,Entity实体通常明确的由Java Code绑定,而非由Seam隐性初始化。

Entity Bean实体不支持双向注入或者上下文分界。对Entity Bean的调用也不会触发验证。

Entity Bean通常不作为JSF的action listener使用,但经常作为JSF组件用于显示或者form提交的后台bean,提供属性功能。 特别是,当Entity作为后台Bean的时候,它会和一个无状态Session Bean扮演的action listener联用,来实现CRUD之类的功能。

默认情况下,Entity Bean被绑定到Conversation Context。他们永远不能被绑定到无状态Context。

注意,在集群环境中,把Entity Bean直接绑定到Conversation或者Session范围的Seam上下文变量,与在有状态Session Bean中保持一个对Entity Bean的引用相比,性能比较差。因此,并非所有的Seam应用程序都会把Entity Bean定义为Seam组件。

Seam实体Bean组建可以使用 Component.getInstance()@In(create=true) 或者直接使用 new 操作来实例化。

组件名字


所有Seam组件都需要名字。我们可以通过 @Name 注解来命名组件:

@Name("loginAction") @Stateless public class LoginAction implements Login {     ... }

这个名字是 seam component name,和EJB规范定义的任何其他名字都没有关系。 但是,Seam组件名字就作为JSF管理的Bean Name使用,因此,可以理解为这两个概念是等同的。

@Name 不是定义组件名称的唯一方式,但是我们总得要在 某个地方 来指定名字。 否则,Seam 注解的其他部分就无法工作。

就如同在JSF中,Seam组件实例绑定成上下文变量时,其名字通常和组件名相同。 因此,例如我们可以通过 Contexts.getStatelessContext().get("loginAction") 来访问 LoginAction。 特别是,不管Seam自己何时初始化一个组件,它将这个新实例以组件的名字绑定成一个变量。 但是,又和JSF一样,应用程序也可以把组件绑定成其他的上下文变量,只需通过API编程调用。 例如,当前登录的用户(User)可以被绑定成为Session上下文中的 currentUser 变量,而同时,另一个用作某种管理功能的用户则被绑定成对话上下文的 user 变量。

对非常大型的应用程序,经常使用全限定名;内置的Seam组件就是这样。

@Name("com.jboss.myapp.loginAction") @Stateless @Interceptors(SeamInterceptor.class) public class LoginAction implements Login {     ... }

我们可以在Java代码和JSF表达式语言中使用全限定的组件名称。

<h:commandButton type="submit" value="Login"                  action="#{com.jboss.myapp.loginAction.login}"/>

这很啰嗦,Seam也提供了把全限定名简写的办法。在 components.xml 文件中加入类似这样的一行:

<factory name="loginAction" scope="STATELESS" value="#{com.jboss.myapp.loginAction}"/>

所有的Seam内置组件都有全限定名,但大多数都在Seam jar文件的 components.xml 中简写为简单的名字。

Seam学习笔记---Seam的上下文

基本的Seam上下文

基本的Seam上下文有:

  • Stateless context

  • Event (or request) context

  • Page context

  • Conversation context

  • Session context

  • Business process context

  • Application context

Stateless context(无状态上下文)


那些确实没有状态的组件(主要是无状态Session Bean)总是运行在无状态上下文中(实际上就是上下文无关)。 无状态组件没什么太大的意思,也有争议认为它们不十分面向对象。但不管怎么样,它们还是很重要,并且通常很有用。

Event context(事件上下文)


事件上下文是“最窄”的有状态上下文,是Web Request 上下文的泛化,用以包含其他种类的事件。 然而,与JSF请求的生命周期相关联的事件上下文是事件上下文最重要的实例,并且也是你最常打交道的。 与事件上下文相关联的组件在请求结束时被销毁,但是它们的状态至少在请求的生命周期中是存在并且是定义良好的。

Page context(页面上下文)


页面上下文允许你将状态与一个渲染页面的实例相关联。 你可以在Event Listener中初始化状态,或者在实际渲染页面的时候初始化状态,任何源于该页面的事件都可以访问到这些状态。 这在支持像可点击列表这种的功能时特别有用,列表的内容通过服务器端的数据变化产生。 实际上状态被序列化到了客户端,因此在多窗口操作或者回退按钮的时候,这种结构是非常健壮的。

Conversation context(业务会话上下文)

业务会话上下文是Seam中最核心的概念conversation(业务会话)是从用户的视角看待的一个工作单元。 它可能跨越与用户交互的多个Servlet、多个请求,和多个数据库事务。但是对用户来说,一个业务会话解决一个单一的问题。 例如说:“预订酒店”,“批准合同”,“创建订单”都是业务会话。 你可以将业务会话理解成对一个“use case(用例)”或“user story(用户故事)”的实现,但这种联系并非是必须的。

业务会话保存关于“在此窗口中,用户正在干什么”的状态。在任何时间,一个用户可能同时位于多个业务会话活动中,一般是在几个不同窗口中。 业务会话上下文让我们可以确保不同业务会话的状态不会互相干扰,不会导致Bug。

你可能要花上一点时间才能习惯以这一业务会话的观点来思考你的应用程序。 但一旦你习惯于它,你会喜欢上这个术语,并且再不会不用业务会话来思考了!

一些业务会话仅存在在一次请求中。跨域多个请求的业务会话必须通过Seam提供的annotation注解来划分。

一些业务会话同时也是tasks(任务)。任务是一种业务会话,它特指一个长时间运行的业务过程,当正确完成后,可能会触发一个业务流程状态的转换。Seam为任务划分提供了专门的annocation注解。

业务对话可以是nested(嵌套)的,一个业务对话嵌套“在”一个更大的业务对话中。这是一项高级特性。

通常,业务对话状态实际上由Seam保存在Servlet Session 中,跨越请求。Seam实现了可配置的 conversation timeout,可以自动销毁不活动的业务会话,这就可以确保,如果用户取消对话,用户的登录Session中保存的状态不会无限增长。

对于在一个长时间运行的业务会话中所产生的并发请求,Seam按顺序执行。

除此之外,Seam也可以配置成把对话状态保存在客户端浏览器中。

Session context(Session上下文)


Session上下文保存与用户登录session相关联的状态。虽然当需要在多个业务会话中交换状态的时候这很有用,但我们一般不建议使用Session 上下文保存组件,除非是保存有关登录用户的全局信息。

在JSR-168 Portal环境下,Session上下文代表Portlet上下文。

Business process context (业务流程上下文)


业务流程上下文保存了长时间运行的业务流程相关的状态。这种状态由BPM引擎(jBPM)管理和持久化。 业务流程跨越多个用户的交互,因此状态在多个用户之间通过良好定义的方式共享。 当前的任务决定当前的业务流程实例,业务流程的生命周期通过外置的 process definition language(流程定义语言) 来定义,因此没有特别的annotation注解用于划分业务流程。

Application context(应用上下文)


Application上下文就是Servlet规范中的Servlet上下文。应用程序上下文在保存静态信息方面有用,例如配置数据,引用数据或者元模型。 例如,Seam把自己的配置和元模型保存在应用程序上下文中。

Context variables(上下文变量)


上下文定义了命名空间,一组 context variables(上下文变量)。 这些工作很类似Servlet规范中对Session或Request attributes的定义。 你可以绑定任何你喜欢的值到Context Variable,但通常我们会绑定Seam组件实例到Context Variables。

因此,在上下文中,组件实例是通过上下文变量名字来辨别的(通常是这样,但并非绝对,就和组件名称一样)。 你可以通过程序在特定范围内访问被命名的组件实例,这是通过 Contexts 类进行的,它提供了对 Context 接口的几个线程绑定的实例的访问:

User user = (User) Contexts.getSessionContext().get("user");

你也可以通过名字来设置或修改变量值:

Contexts.getSessionContext().set("user", user);

但通常,我们通过注射(injection)来从上下文中获得组件,并且通过反向注射(outjection)把组件实例返回上下文。

2008年3月21日星期五

有意思(答案见中缝)

据说能答对5道题的人是天才,答对4道的是帅才,答对3道的是将才,答对2道的是奇才,答对1道的是人才,1道都想不出来的是X才

1、一个数字,去掉前面一个数字后,是13。去掉最后一个数字后,是40。这个数字是什么?

2、这一等式很奇怪,0比2大,2比5大,5比0大。为什么?

3、只字加一笔,会是什么字?

4、人加一笔,除了大/个,还有什么字?

5、桌子上有2、1、6三张卡片,请问摆成一个什么数字可以让43整除?
四十三,剪刀石头布,冲,及,129

2008年3月20日星期四

免得老是忘记-toString

为了方便Log4J等方式的调试,显示一个类的实例,通常需要做如下方式的输出:
log.trace(myClassInstance);
此时需要MyClass实现重载 toString()方法,利用Jakarta Common Lang可以很容易实现toString方法,由ToStringBuilder类完成对一个类的细节的显示,参考toString方法的实现如下:

import org.apache.commons.lang.builder.ToStringBuilder;

public String toString() { return ToStringBuilder.reflectionToString(this); }relectionToString()

将利用Java Refelection机制显示类实例的所有属性的信息.

2008年3月17日星期一

看什么呢?老婆

2008年3月12日星期三

Cognos入门指南

2008-01-08至2008-03-12的工作成果

2008年3月10日星期一

Cognos报表展示的参数传递

如何调用已发布到Enterprise server的ppx报表(参数传递)

Cognos的内容一般作为网页中某一特定的帧来展现。我们可以在外部统一的用户交互界面中收集用户递交的查询条件(一般用JSP实现),在检查完用户输入的有效性之后,把这些参数按照Cognos约定的标准,以POST的方式传到某一帧中的Cognos的网管。Cognos网管就会把用户查询的结果返回到该帧中。

下面是一个接口调用的实例:
假设服务器名称为:servername
ppx报表发布到enterprise server之后在enterprise server的根目录下,名称为:testreport
如果我们要对这个报表进行访问,可通过如下url对报表进行调用:http://test/cognos/ cgi-bin/ppdscgi.exe?DC=R&E=%2Ftestreport
如果用户要求访问的是一个可动态分析的cube,那么相应的url为
http://test/cognos/ cgi-bin/ppdscgi.exe?DC=Q&E=%2Fcubename

其中:%2F是一个URL使用的转意符,它的原型是符号“\”。

如果报表或Cube是发布于一个文件夹test中的,那么相应的url为:

http://test/cognos/ cgi-bin/ppdscgi.exe?DC=R&E=%2Ftest%2Ftestreport



通过以上的接口可以访问到任意发布到Powerplay Enterprise Server的报表或Cube。如果要向报表或Cube传递过滤条件,可采用下面的调用标准。

例如在Enterprise Server发布有报表ICBC,该报表开放了四个传参接口(Years,Products,Locations,Channles)。用户可以选择向其中的某几个接口传参。

如果选择“Products”为“Outdoor Products”则调用

http://test/cognos/cgi-bin/ppdscgi.exe?DC=R&E=%2Ficbc&DM=Products&FC=0%09Outdoor%20Products&ZZ=X

其中&DM=Products //表示要过滤维度Products

&FC=0%09Outdoor%20Products //表示维度Products的过滤值



如果是过滤两个维度,例如过滤“Products”和“Locations”则调用

http://info/cognos/cgi-bin/ppdscgi.exe?DC=R&E=%2Ficbc&DM=Products%09Locations&FC=0%09Outdoor%20Products%091%09Europe&ZZ=X

其中&DM=Products%09Locations //维度间用%09分开

&FC=0%09Outdoor%20Products%091%09Europe //维度值从0开始标号



如果是过滤三个维度,例如过滤“Products”和“Locations”及“Channels”则调用

http://info/cognos/cgi-bin/ppdscgi.exe?DC=R&E=%2Ficbc2&DM=Products%09Locations%09Channels&FC=0%09Environmental%20Line%091%09Europe%092%09Independent&ZZ=X

其中&DM=Products%09Locations%09Channels //维度间用%09分开

&FC=0%09Outdoor%20Products%091%09Europe%092%09Independent

//维度值从0开始标号



在每条Url后添加&ZZ=X,表示参数传递结束。



注意:维度过滤值必须用该维度节点的code

2008年3月7日星期五

真假猴王

  千年以前
  你匍匐地下
  明知生死未来痛苦欢乐
  但
  你无须说破
  生命历程里的漫漫长路
  说与不说
  对任何人
  都是轮回的花开花落
  
  千年以前
  你伏在地下
  明知是非真假
  但
  你不能说破
  那两个惊天动地的神猴
  说出来
  对天对地
  都是难躲的祸
  
  千年以后
  你伏在我心中
  明知爱与不爱
  但
  你无法说破
  那深深寂寞里的烟花
  说出来
  对你对我
  都是遗憾三生的错

2008年3月5日星期三

Operational Data Storage

ODS是一个面向主题的、集成的、可变的、当前的细节数据集合,用于支持企业对于即时性的、操作性的、集成的全体信息的需 求。常常被作为数据仓库的过渡,也是数据仓库项目的可选项之一。

根据Bill.Inmon的定义,“数据仓库是面向主题的、集成的、稳定的、随时间变化的,主要用于决策支持的数据库系统”

ODS是一个面向主题的、集成的、可变的、当前的细节数据集合,用于支持企业对于即时性的、操作性的、集成的全体信息的需 求。常常被作为数据仓库的过渡,也是数据仓库项目的可选项之一。

在Kimball的<<数据仓库生命周期工具集The Data WareHouse Liftcycle Toolkit>>,他是这样定义的

1. 是操作型系统中的集成,用于当前,历史以及其它细节查询(业务系统的一部分)

2. 为决策支持提供当前细节数据(数据仓库的一部分)

因此操作数据存储(ODS) 是用于支持企业日常的全局应用的数据集合,ODS的数据具有面向主题、集成的、可变的和数据是当前的或是接近当前的4个基本特征。同样也可以看出ODS是介于DB和DW 之间的一种数据存储技术,和原来面向应用的分散的DB相比,ODS中的数据组织方式和数据仓库(DW)一样也是面向主题的和集成的,所以对进入ODS的数 据也象进入数据仓库的数据一样进行集成处理。另外ODS只是存放当前或接近当前的数据,如果需要的话还可以对ODS中的数据进行增、删和更新等操 作,虽然DW中的数据也是面向主题和集成的,但这些数据一般不进行修改,所以ODS和DW的区别主要体现数据的可变性、当前性、稳定性、汇总度上。

由于ODS仍然存储在普通的关系数据库中,出于性能、存储和备份恢复等数据库的角度以及对源数据库的性能影响角度,个人不建议ODS保存相当长周期的数据,同样ODS中的数据也尽量不做转换,而是原封不动地与业务数据库保持一致。即ODS只是业务数据库的一个备份或者映像,目的是为了使数据仓库的处理和决策支持要求与OLTP系统相隔离,减少决策支持要求对OLTP系统的影响。

为什么需要有一个ODS系统呢?一般在带有ODS的系统体系结构中,ODS都具备如下几个作用:

1) 在业务系统和数据仓库之间形成一个隔离层。

一 般的数据仓库应用系统都具有非常复杂的数据来源,这些数据存放在不同的地理位置、不同的数据库、不同的应用之中,从这些业务系统对数据进行抽取并不是一件 容易的事。因此,ODS用于存放从业务系统直接抽取出来的数据,这些数据从数据结构、数据之间的逻辑关系上都与业务系统基本保持一致,因此在抽取过程中极 大降低了数据转化的复杂性,而主要关注数据抽取的接口、数据量大小、抽取方式等方面的问题。

2) 转移一部分业务系统细节查询的功能

在 数据仓库建立之前,大量的报表、分析是由业务系统直接支持的,在一些比较复杂的报表生成过程中,对业务系统的运行产生相当大的压力。ODS的数据从粒度、 组织方式等各个方面都保持了与业务系统的一致,那么原来由业务系统产生的报表、细节数据的查询自然能够从ODS中进行,从而降低业务系统的查询压力。

3) 完成数据仓库中不能完成的一些功能。

一 般来说,带有ODS的数据仓库体系结构中,DW层所存储的数据都是进行汇总过的数据和运营指标,并不存储每笔交易产生的细节数据,但是在某些特殊的应用中,可能需要 对交易细节数据进行查询,这时就需要把细节数据查询的功能转移到ODS来完成,而且ODS的数据模型按照面向主题的方式进行存储,可以方便地支持多维分析 等查询功能。即数据仓库从宏观角度满足企业的决策支持要求,而ODS层则从微观角度反映细节交易数据或者低粒度的数据查询要求。

在一个没有ODS层的数据仓库应用系统体系结构中,数据仓库中存储的数据粒度是根据需要而确定的,但一般来说,最为细节的业务数据也是需要保留的,实际上 也就相当于ODS,但与ODS所不同的是,这时的细节数据不是“当前、不断变化的”数据,而是“历史的,不再变化的”数据。这样的数据仓库的存储压力和性能压力都是比较大的,因此对数据仓库的物理设计和逻辑设计提出了更高的要求。

房价上涨的原因

以前,有个地主有很多地,找了很多长工干活,地主给长工们盖了一批团结楼住着,一天,地主的谋士对地主说:东家,长工们这几年手上有点钱了,他们住你的房子,每月交租子,不划算,反正他们永远住下去,你干脆把房子卖给他们起个名堂叫做-----公房出售!告诉他们房子永远归他们了,可以把他们这几年攒的钱收回来,地主说:不错,那租金怎么办?谋士说:照收不误,起个日本名儿,叫物业费!地主很快实行了,赚了好多钱,长工们那个高兴啊!
  过了几年,地主的村子发展成城镇了,有钱人越来越多,没地方住,谋士对地主说:东家,长工们这几年手上又有钱了,咱们给他们盖新房子,起个名堂叫做旧城改造,他们把手上的钱给我们,我们拆了房子盖新的,叫他们再买回去,可以多盖一些卖给别人,地主又实行了,这次,有些长工们不高兴了,地主的家丁派上用途了,长工们打掉牙只好往肚子里咽,地主又赚了好多钱。
  又过了几年,地主的村子发展成大城市了,有钱人更多了,地主的土地更值钱了,谋士对地主说:东家,咱们把这些长工的房子拆了,在这个地方建别墅,拆出来的地盖好房子卖给那些有钱的大款还能赚一笔,地主说:长工们不干怎么办?谋士说:咱给他们钱多点儿,起个名堂叫货币化安置,咱再到咱们的猪圈旁边建房子,起个名堂叫经济适用房,给他们修个马车道让他们到那边买房住,地主说:他们钱不够怎么办?谋士说:从咱家的钱庄借前给他们,一年6分利,咱这钱还能生钱崽,又没风险,地主又实行了,长工们拿到钱,地主的经济适用房到现在才建了一间,长工们只好排队等房子,直到现在,还等着呢——
  于是,长工们开始闹事了,地主有点慌,忙问谋士怎么办?谋士说:赶紧通知长工们,房子要跌价了,别买了,租房住吧,正好把我们的猪圈租给他们,结果,这么多年后,长工们的钱全没了,还在租房住,直到永远 。

2008年3月4日星期二

鱼我所欲也

鱼,我所欲也,熊掌,亦我所欲也,二者不可得兼,舍鱼而取熊掌者也。生,亦我所欲也,义,亦我所欲也,二者不可得兼,舍生而取义者也。生亦我所欲,所欲有甚于生者,故不为苟得也。死亦我所恶,所恶有甚于死者,故患有所不避也。如使人之所欲莫甚于生,则凡可以得生者何不用也?使人之所恶莫甚于死者,则凡可以避患者何不为也?由是则生而有不用也;由是则可以避患而有不为也。是故所欲有甚于生者,所恶有甚于死者。非独贤者有是心也,人皆有之,贤者能勿丧耳。

一箪食,一豆羹,得之则生,弗得则死。呼尔而与之,行道之人弗受;蹴尔而与之,乞人不屑也。

万钟则不辨礼义而受之,万钟于我何加焉!为宫室之美,妻妾之奉,所识穷乏者得我欤?向为身死而不受,今为宫室之美为之;向为身死而不受,今为妻妾之奉为之;向为身死而不受,今为所识穷乏者得我而为之:是亦不可以已乎?此之谓失其本心。

2008年2月28日星期四

龙生九子,各有不同

  龙生九子之一·囚牛

  囚牛,是龙生九子中的老大,平生爱好音乐,它常常蹲在琴头上欣赏弹拨弦拉的音乐,因此琴头上便刻上它的遗像。这个装饰现在一直沿用下来,一些贵重的胡琴头部至今仍刻有龙头的形象,称其为“龙头胡琴”。

  龙生九子之二·睚眦

  睚眦,是老二,平生好斗喜杀,刀环、刀柄、龙吞口便是它的遗像。这些武器装饰了龙的形象后,更增添了慑人的力量。它不仅装饰在沙场名将的兵器上,更大量地用在仪仗和宫殿守卫者武器上,从而更显得威严庄重。

  龙生九子之三·嘲风

  嘲风,形似兽,是老三,平生好险又好望,殿台角上的走兽是它的遗像。这些走兽排列着单行队,挺立在垂脊的前端,走兽的领头是一位骑禽的“仙人”,后面依次为:龙、凤、狮子、天马、海马、狻猊、押鱼、獬豸、斗牛、和行什。它们的安放有严格的等级制度,只有北京故宫的太和殿才能十样俱全,次要的殿堂则要相应减少。嘲风,不仅象征着吉祥、美观和威严,而且还具有威慑妖魔、清除灾祸的含义。嘲风的安置,使整个宫殿的造型既规格严整又富于变化,达到庄重与生动的和谐,宏伟与精巧的统一,它使高耸的殿堂平添一层神秘气氛。

  龙生九子之四·蒲牢

  蒲牢,形似盘曲的龙,排行第四,平生好鸣好吼,洪钟上的龙形兽钮是它的遗像。原来蒲牢居住在海边,虽为龙子,却一向害怕庞然大物的鲸鱼。当鲸鱼一发起攻击,它就吓得大声吼叫。人们根据其“性好鸣”的特点,“凡钟欲令声大音”,即把蒲牢铸为钟纽,而把敲钟的木杵作成鲸鱼形状。敲钟时,让鲸鱼一下又一下撞击蒲牢,使之“响入云霄”且“专声独远”。

  龙生九子之五·狻猊

  狻猊,形似狮子,排行第五,平生喜静不喜动,好坐,又喜欢烟火,因此佛座上和香炉上的脚部装饰就是它的遗像。相传这种佛座上装饰的狻猊是随着佛教在汉代由印度人传入中国的,至南北朝时期,我国的佛教艺术上已普遍使用,这种造型经过我国民间艺人的创造,使其具有中国的传统气派,后来成了龙子的老五,它布置的地方多是在结跏趺坐或交脚而坐的佛菩萨像前。明清之际的石狮或铜狮颈下项圈中间的龙形装饰物也是狻猊的形象,它使守卫大门的中国传统门狮更为睁崃威武。

  龙生九子之六·霸下

  霸下,又名赑屃,形似龟,是老六,平生好负重,力大无穷,碑座下的龟趺是其遗像。传说霸下上古时代常驮着三山五岳,在江河湖海里兴风作浪。后来大禹治水时收服了它,它服从大禹的指挥,推山挖沟,疏遍河道,为治水作出了贡献。洪水治服了,大禹担心霸下又到处撒野,便搬来顶天立地的特大石碑,上面刻上霸下治水的功迹,叫霸下驮着,沉重的石碑压得它不能随便行走。霸下和龟十分相似,但细看却有差异,霸下有一排牙齿,而龟类却没有,霸下和龟类在背甲上甲片的数目和形状也有差异。霸下又称石龟,是长寿和吉祥的象征。它总是吃力地向前昂着头,四只脚拼命地撑着,挣扎着向前走,但总是移不开步。我国一些显赫石碑的基座都由霸下驮着,在碑林和一些古迹胜地中都可以看到。

  龙生九子之七·狴犴

  狴犴,又名宪章,形似虎,是老七。它平生好讼,却又有威力,狱门上部那虎头形的装饰便是其遗像。传说狴犴不仅急公好义,仗义执言,而且能明辨是非,秉公而断,再加上它的形象威风凛凛,囚此除装饰在狱门上外,还匐伏在官衙的大堂两侧。每当衙门长官坐堂,行政长官衔牌和肃静回避牌的上端,便有它的形象,它虎视眈眈,环视察看,维护公堂的肃穆正气。

  龙生九子之八·负屃

  负屃,似龙形,排行老八,平生好文,石碑两旁的文龙是其遗像。我国碑碣的历史久远,内容丰富,它们有的造型古朴,碑体细滑、明亮,光可鉴人;有的刻制精致,字字有姿,笔笔生动;也有的是名家诗文石刻,脍炙人口,千古称绝。而负屃十分爱好这种闪耀着艺术光彩的碑文,它甘愿化做图案文龙去衬托这些传世的文学珍品,把碑座装饰得更为典雅秀美。它们互相盘绕着,看去似在慢慢蠕动,和底座的霸下相配在一起,更觉壮观。

  龙生九子之九·螭吻

  螭吻,又名鸱尾,鱼形的龙。相传是大约在南北朝时,由印度‘摩竭鱼’随佛教传入的。它是佛经中,雨神座下之物,能够灭火。故此,螭吻由此变化出来,所以它多安在屋脊两头,作消灾灭火的功效。,龙形的吞脊兽,是老九,口阔噪粗,平生好吞,殿脊两端的卷尾龙头是其遗像。《太平御览》有如下记述:“唐会要目,汉相梁殿灾后,越巫言,‘海中有鱼虬,尾似鸱,激浪即降雨’遂作其像于尾,以厌火祥。”文中所说的“巫”是方士之流,“鱼虬”则是螭吻的前身。螭吻属水性,用它作镇邪之物以避火

Cognos小技巧1

1,机构中数据分级控制,
case
left (#"'"+$account.personalInfo.businessPhone+"'"# ,1)
when '0' then [ocrm_person].[RPTORGDIMEN].[CENTRE]
when '1' then [ocrm_person].[RPTORGDIMEN].[PROVINCE]
when '2' then [ocrm_person].[RPTORGDIMEN].[CITY]
when '3' then [ocrm_person].[RPTORGDIMEN].[BRANCHCODE]
when '4' then [ocrm_person].[RPTORGDIMEN].[NODE]
else #"'"+$account.personalInfo.email+"'"#
end = #"'"+$account.personalInfo.email+"'"#

2,Cognos外部链接登录格式
http://192.168.5.83:9300/p2pd/servlet/dispatch?CAMNamespace=default&CAMUsername=administrator&CAMPassword=123456

2008年1月25日星期五

袁天罡称骨

据说这是袁天罡道长研究出来的,是流传比较广的一种算命方法。现在将具体的算法贴出来,大家可以自己算算。首先说一句,任何算法都不可能是100%正确的,而且即便100%正确,也是可以因为个人的行为(比方说积德行善或者作恶多端)而改变的,历史上也很多这样的例子,总之,提醒各位千万不要太执著于此!!!如果因此给谁的心情蒙上阴影,偶会深感不安的。袁天罡称骨算法:根据个人八字(即出生年月日和时辰),分别在后面所附内容中查出出生年的重量、出生月的重量、出生日的重量以及出生时辰的重量,将四个重量相加所得即为八字重量。根据八字重量去查相关的批注诗。
一般说来,八字重的比较不容易振的住,也就是说不容易被邪物侵扰,当然玩招魂招仙的游戏也不容易成功。显然不是绝对的八字越重越好,轻的也有比较好的,但从一般意义上说,八字重的普遍比轻的得到的批示要好,所谓一般意义也就是说这里的好在有的人眼中可能未必是好。举个例子吧:1971年正月初一子时出生的人可以查到年的重量为1两7钱,月的重量为6钱,日的重量为5钱,时辰的重量为1两6钱,将之相加: 1两7+6钱+5钱+1两6=1.7+0.6+0.5+1.6=4.4=4两4钱。然后查4两4钱的批注诗: 4两4:来事由天莫苦求,须知福禄胜前途,当年财帛难如意,晚景欣然便不忧出生年的重量:出生年的重量是以六十年为周期的(也就是说相差六十年的年份重量相同)
这是年的 1941:6钱 1942:8钱 1943:7钱 1944:5钱 1945:1两5 1946:6钱 1947:1两6 1948:1两5 1949:7两 1950:9钱| 1951:1两2 1952:1两 1953:7钱 1954:1两5 1955:6钱 1956:5钱 1957:1两4 1958:1两4 1959:9钱 1960:7钱 1961:7钱 1962:9钱 1963:1两2 1964:8钱 1965:7钱 1966:1两3 1967:5钱 1968:1两4 1969:5钱 1970:9钱 1971:1两7 1972:5钱 1973:7钱 1974:1两2 1975:8钱 1976:8钱 1977:6钱 1978:1两9 1979:6钱 1980:8钱 1981:1两6 1982:1两 1983:7钱 1984:1两2 1985:9钱 1986:6钱 1987:7钱 1988:1两2 1989:5钱 1990:9钱 1991:8钱 1992:7钱 1993:8钱 1994:1两5 1995:9钱 1996:1两6 1997:8钱 1998:8钱 1999:1两9 2000:1两2

月的重量:一月:6钱 二月:7钱 三月:1两8 四月:9钱五月:5钱 六月:1两6 七月:9钱 八月:1两5 九月:1两8 十月:8钱 十一月:9钱 十二月:5钱

出生日的重量:初一:五钱 初二:一两 初三:八钱 初四:一两五初五:一两六 初六:一两五 初七:八钱 初八:一两六初九:八钱 初十:一两六十一:九钱 十二:一两七十三:八钱 十四:一两七 十五:一两 十六:八钱十七:九钱 十八:一两八 十九:五钱 二十:一两五廿一:一两廿二:九钱 廿三:八钱 廿四:九钱廿五:一两五 廿六:一两八 廿七:七钱 廿八:八钱廿九:一两六 三十:六钱
时辰: 子时:一两六丑时:六钱寅时:七钱 卯时:一两辰时:九钱 巳时:一两六午时:一两 未时:八钱申时:八钱 酉时:九钱戌时:六钱亥时:六钱时辰表:子时:23:00--1:00 丑时: 1:00--3:00 寅时: 3:00--5:00 卯时: 5:00--7:00 辰时: 7:00--9:00 已时: 9:00--11:00 午时:11:00--13:00 未时:13:00--15:00 申时:15:00--17:00 酉时:17:00--19:00 戌时:19:00--21:00 亥时:21:00--23:00

批注诗 [replyview]2两1:短命非业谓大凶,平生灾难事重重,凶祸频临限逆境,终世困苦事不成 2两2:身寒骨冷苦伶仃,此命推来行乞人,劳劳碌碌无度日,中年打拱过平生 2两3:此命推来骨轻轻,求谋做事事难成,妻儿兄弟应难许,别处他乡作散人 2两4:此命推来福禄无,门庭困苦总难荣,六亲骨肉皆无靠,流到他乡作老人 2两5:此命推来祖业微,门庭营度似希奇,六亲骨肉如水炭,一世勤劳自把持 2两6:平生一路苦中求,独自营谋事不休,离祖出门宜早计,晚来衣禄自无忧 2两7:一生做事少商量,难靠祖宗作主张,独马单枪空作去,早年晚岁总无长 2两8:一生作事似飘蓬,祖宗产业在梦中,若不过房并改姓,也当移徒二三通 2两9:初年运限未曾亨,纵有功名在后成,须过四旬方可上,移居改姓使为良 3两:劳劳碌碌苦中求,东走西奔何日休,若能终身勤与俭,老来稍可免忧愁 3两1:忙忙碌碌苦中求,何日云开见日头,难得祖基家可立,中年衣食渐无忧 3两2:初年运错事难谋,渐有财源如水流,到的中年衣食旺,那时名利一齐来 3两3:早年做事事难成,百计徒劳枉费心,半世自如流水去,后来运到始得金 3两4:此命福气果如何,僧道门中衣禄多,离祖出家方得妙,终朝拜佛念弥陀 3两5:生平福量不周全,祖业根基觉少传,营事生涯宜守旧,时来衣食胜从前 3两6:不须劳碌过平生,独自成家福不轻,早有福星常照命,任君行去百般成 3两7:此命般般事不成,弟兄少力自孤成,虽然祖业须微有,来的明时去的暗 3两8:一生骨肉最清高,早入学门姓名标,待看年将三十六,蓝衣脱去换红袍 3两9:此命少年运不通,劳劳做事尽皆空,苦心竭力成家计,到得那时在梦中 4两:平生衣禄是绵长,件件心中自主张,前面风霜都受过,从来必定享安泰 4两1:此命推来事不同,为人能干异凡庸,中年还有逍遥福,不比前年云未通 4两2:得宽怀处且宽怀,何用双眉总不开,若使中年命运济,那时名利一齐来 4两3:为人心性最聪明,做事轩昂近贵人,衣禄一生天数定,不须劳碌是丰亨 4两4:来事由天莫苦求,须知福禄胜前途,当年财帛难如意,晚景欣然便不忧 4两5:福中取贵格求真,明敏才华志自伸,福禄寿全家道吉,桂兰毓秀晚荣臻 4两6:东西南北尽皆通,出姓移名更觉隆,衣禄无亏天数定,中年晚景一般同 4两7:此命推来旺末年,妻荣子贵自怡然,平生原有滔滔福,可有财源如水流 4两8:幼年运道未曾享,苦是蹉跎再不兴,兄弟六亲皆无靠,一身事业晚年成 4两9:此命推来福不轻,自立自成显门庭,从来富贵人亲近,使婢差奴过一生 5两:为利为名终日劳,中年福禄也多遭,老来是有财星照,不比前番目下高 5两1:一世荣华事事通,不须劳碌自亨通,兄弟叔侄皆如意,家业成时福禄宏 5两2:一世亨通事事能,不须劳思自然能,宗施欣然心皆好,家业丰亨自称心 5两3:此格推来气象真,兴家发达在其中,一生福禄安排定,却是人间一富翁 5两4:此命推来厚且清,诗书满腹看功成,丰衣足食自然稳,正是人间有福人 5两5:走马扬鞭争名利,少年做事废筹论,一朝福禄源源至,富贵荣华显六亲 5两6:此格推来礼仪通,一生福禄用无穷,甜酸苦辣皆尝过,财源滚滚稳且丰 5两7:福禄盈盈万事全,一生荣耀显双亲,名扬威震人钦敬,处世逍遥似遇春 5两8:平生福禄自然来,名利兼全福禄偕,雁塔提名为贵客,紫袍金带走金鞋 5两9:细推此格妙且清,必定才高礼仪通,甲第之中应有分,扬鞭走马显威荣 6两:一朝金榜快提名,显祖荣宗立大功,衣食定然原欲足,田园财帛更丰盈 6两1:不做朝中金榜客,定为世上一财翁,聪明天赋经书熟,名显高克自是荣 6两2:此名生来福不穷,读书必定显亲荣,紫衣金带为卿相,富贵荣华皆可同 6两3:命主为官福禄长,得来富贵定非常,名题金塔传金榜,定中高科天下扬 6两4:此格权威不可当,紫袍金带坐高堂,荣华富贵谁能及,积玉堆金满储仓 6两5:细推此命福不轻,安国安邦极品人,文绣雕梁政富贵,威声照耀四方闻 6两6:此格人间一福人,堆金积玉满堂春,从来富贵由天定,正笏垂绅谒圣君 6两7:此名生来福自宏,田园家业最高隆,平生衣禄丰盈足,一世荣华万事通 6两8:富贵由天莫苦求,万金家计不须谋,十年不比前番事,祖业根基水上舟 6两9:君是人间衣禄星,一生福贵众人钦,纵然福禄由天定,安享荣华过一生 7两: 此命推来福不轻,不须愁虑苦劳心,一生天定衣与禄,富贵荣华过一生 7两1:此名生来大不同,公侯卿相在其中,一生自有逍遥福,富贵荣华极品隆 7两2:此格世界罕有

2008年1月22日星期二

Cognos权限管理注意的地方

Cognos权限管理注意的地方

Everyone
This group represents all authenticated users and the Anonymous user account. The membership of this group is maintained by the product and cannot be viewed or altered.

You can use the Everyone group to set default security quickly. For example, to secure a report, you grant read, write, or execute permissions to the report for the Everyone group. After this security is in place, you can grant access to the report to other users, groups, or roles, and remove the group Everyone from the security policy for this report. Then, only users, groups, and roles that you specified have access granted to the report.

You can use the Everyone group to apply security during deployment , but you cannot deploy the group itself .

System Administrators
This is a special role. Members of this role are considered root users or super users. They may access and modify any object in the content store, regardless of any security policies set for the object. Only members of the System Administrators role can modify the membership of this role.

The System Administrators role cannot be empty. If you do not want to use System Administrators, you can create an empty group in the Cognos namespace or in your authentication provider, and add this group to the membership of the System Administrators role.

When this role is created during the content store initialization, the group Everyone is included in its membership. This means that all users have unrestricted access to the content store. Immediately after installing and configuring Cognos 8, you must modify the initial security settings for this role and remove the group Everyone from its membership .

You can deploy this role .

将everyone 从System administrator 删除,然后将everyone禁用!!!!

2008年1月15日星期二

探讨数据仓库与商业智能需求与需求分析(转载)

探讨数据仓库与商业智能需求与需求分析


  各位朋友,我是一名来自从事商业智能项目开发的一名一线技术工作者,我曾在这个领域从事过从程序员,系统分析员到项目经理多种岗位,从2002年开始,我亲身经历了多个不同规模的数据仓库与商业智能项目,经历了甲方和乙方的角色变换,我试图以一个一线bi从业者的体会,为众多朋友描绘出这个充满了激情与失落的bi需求的最直白的面目,以及结合自己的经验,试图从bi的本质观点(如何创造价值)出发,探讨"什么bi需求是有效的,怎么做有效的bi需求"这两个做bi需求不可回避,却又容易被淡忘的问题。并提出和阐述我认为做bi需求应该与发展企业价值链相结合思考的观点。

  bi界内,有一句几乎每个bi实施人员都备感到无奈,却又不得不承认的话,客户真正的需求往往是从项目投产那一刻才真正开始,仿佛bi项目天生就注定是一场的吃力不讨好的恶梦,。

  在决定bi实施成败与效果中,需求无疑是雷区最多的地方。对于bi项目而言,需求是个让人又爱又恨的怪圈。几乎所有bi项目都诞生自bi销售人员所描绘出的华丽前景,以及由此所激发出来的充满理想色彩和浪漫情怀的客户需求,是一个美妙的梦中情人;而在bi界众多周知的是,bi的需求又是一个最折磨人,最让人心力交瘁的顽皮孩子。

  那么,究竟商业智能是一样什么样的东西呢,商业智能的需求为什么同时具备了可爱和可恨两种自相矛盾的特质呢,让我们先从认识商业智能开始。

  第一章回 商业智能的来龙去脉

  传统以来,计算机一直被俗称之为电脑,把计算机和智能划上了等号,然而,我相信在坐有计算机常识的人都明白,除了科学幻想外,我们日常实际工作和生活中使用的计算机其实是个傻瓜,他只会毫不变通地执行的预定的程序,所以如果说计算机有智能,程序是智能的核心,再进一步说,所谓的智能的核心就是用程序来演义的逻辑, 在这种以程序为核心的体系下,数据充其量只是程序的一个附属,如果用游客进公园的大门比喻成一套非常简单的程序系统,公园的大门和配套的验票人员是程序,数据是门票,用过一次就扔了,最多拿个废纸箩装起来,一般也不会再有什么作用了,这就是过往在林林总总的政府和企业的计算机系统中数据所遭受的普遍下场了。

  附图描述信息化发展规律,从60年代计算机逐渐普及以来,计算机的应用领域无论在深度和广度都有了质的拓展,而从总体的应用水平来说,可以划分为以下三个阶段(如图11):这三个阶段与不是用单纯的技术高低来划分的,而是从应用的影响层面来划分。

  第一个阶段是基础信息化阶段,这个阶段从应用面来说,主要是解决数据处理电子化的问题,在这一阶段,机构内往往是一些数据处理工作量最大的部门首先采用了信息技术把手工数据工作电子化,如财务系统,计算机辅助设计系统,电子数据交换系统等等,实现了信息处理的电子自动化无论在人力投入和纸张损耗等方面无疑节约产生了具大的效益,可惜这些信息的关联面是非常有限的,甚至可以说离开了这些系统的主要用户,别人是看不懂这些数据的,而这些用户在企业中往往是少数的专业人士。

  第二阶段是企业级信息化阶段,这一阶段政府机构与企业往往已经拥有了几个分别建设的业务处理系统,机构期望从总体角度建设高度集中的、或互相联接的综合业务管理系统,如miserpoa等等,这个阶段的应用核心是通过实施一个企业级的应用系统实现企业的业务流程或者管理流程的信息流畅,以此来提高企业的运作效率,以实现流程的自动化。

  第三阶段是目前的近几年刚起步的发展趋势,应该说也是现在很多企业完成了第二阶段的信息化建设后,所面临的下一步信息化该怎么走的问题,由于还没成为历史,所以我这里大胆提出我的定义,我认为,这个阶段应该是企业的战略价值信息化阶段,因为这个阶段的根本目标,是实现整个企业的系统思考(systems thinkings)能力,这个阶段的应用层面,应该说已经渗透到从企业管理到企业文化的方方面面,当然,这个阶段的形成与产生绝对是离不开前两个阶段所打下的信息化坚实的基础,本身这三个阶段也是承前启后,不可分割的,而我认为第三阶段对于企业发展更有深远的发展意义,我把企业形象地比喻一个人的话,第一阶段是针对手指的自动化,第二阶段是针对耳朵的自动化,第三阶段是针对大脑的自动化。

  第三阶段正是商业智能走上历史舞台并且成为主角的时代,也是企业求生存求发展不得不走向商业智能的历史选择,这个选择的根源,我认为,不是技术的进步,当然不可否认,技术的进步创造了物质上的条件,然而从因果关系的动因角度来做说,企业选择商业智能的根本原因,是市场竞争的必然。

  这样,我们不得不偏离一下主题,稍微看看现在市场的竞争给企业带来的压力,随着市场竞争的日益激烈,目前营销竞争方式已经从一个大众化营销阶段进入了一个差异化营销阶段,进而上升到一个价值链整合营销阶段,竞争从拼生产能力到拼服务能力,最终必然上升到拼决策能力,现在的企业一把手可能比历史上任何一个时期的皇帝还要难当,一则是现在企业内部组织机构的复杂性肯定超过100年前的封建帝国,生产环节,销售环节,财务环节,人力环节方方面面,缺一不可,协调一个企业的正常运作已经越来越需要精确化的管理,压缩管理成本已经是任何一位企业领导人都需要认真对待的问题,二则企业的外部环境瞬息万变,拜高度商业化所赐,市场的潮流和态势可能已经达到了一月或者数月一变的程度,一个判断的失误可能就会把企业带入覆灭的境地,在这种内外压力的夹攻中,一个领导的个人决策能力是不可能不达到人的极限,这个时候,企业的信息系统能做什么,当一个领导要了解能反映企业运行状态的一些重要的信息的时候,我们目前的企业的信息系统能迅速给出一个答案吗?

  很遗憾,不能,也很幸运,就是因为不能,才有我今天这个报告的主题。

第二章回 什么是商业智能

  越来越多企业已经认识到,数据是资产的重要组成部分,以前,企业可能把过期的数据看成是过期门票,随意抛弃,而当企业的领导要做出一个准确有力的决策的时候,终于发现,没有数据啊! 很多人说,不对啊,企业不是已经在计算机设备和软件上投入了大量的资金,做了很多业务系统了吗,不是有很多数据吗? 为什么不能用呢,这个问题问得实在是太好了,我相信每个人都在问这个简单而其实是最深刻的问题,为什么我们的数据不能用!

  过去数年里,几乎每一个企业都建立了自己的信息中心,收集和整理了大量的数据,但是这些数据又带来了始料不及的新问题,就是数量之大种类之浩瀚繁杂远远超过了可以控制和理解的范围,数据库变成了数据监狱,数据一进去就十有八九成了囚犯,而数据一旦过时,要么就被束之高阁,无情地被判了无期徒刑,要么就象碎成纸片的机要文件一样被销毁了。怎么让这些数据囚犯变成有价值的决策依据,进而成为有价值的生产要素,这就是商业智能的目的所在。

  实际上,给商业智能一个完整的定义是很难的,但是,从商业智能的产生根源的角度而言,可以概括为:商业智能是用来实现数据向信息转变,信息向知识转变,知识向价值转变的这么一个过程,以及这个过程中所使用到的种种技术和工具。

  由于商业智能是围绕着数据来做文章的,数据仓库也可以说是商业智能的核心环节,很多情况下,习惯性地,由于两者有如此密切的关系,所以在很多项目命名时,往往是把数据仓库和商业智能相提并论,有时这会给人一种很混淆的感觉。一般来说,上面所描述的是一个广义上的商业智能概念,在这个概念层面上,数据仓库是其中非常重要的组成部分,数据仓库从概念上更多地侧重在对各项企业各类信息的整合工作,包括了数据的迁移,数据的组织和存储,数据的管理与维护这些我们平常称之为后台的基础性的数据准备工作,与之对应,侠义的商业智能概念则侧重在对数据的查询,报表、多维/联机数据分析、数据挖掘和数据可视化工具这些平常称之为所谓前台的数据应用方面。

  第三章回 商业智能的需求

  前面我很罗嗦地交代了商业智能的来龙去脉,我希望让各位知道的是,商业智能需求天生就注定了是不好弄的,为什么,一句话可以概括,因为这是脑子工程,是一把手的工程!决策,其本身就是一个很个性化的事情,每个人的思维方式和思维习惯千差万别,加上性格偏向和个人喜好等因素,好与不好本身就是个价值判断,不是一个是非分明的逻辑判断。说穿了,商业智能的需求就不可能有什么标准的模式,因为即使从人工智能的理论角度,现在也还没有一个方法可以完全地模拟人脑的运做,所以对商业智能需求的定义和控制过程事实上就变成了对人脑的控制过程,如果需求是做到一把手的头上的,想控制一把手的想法可不是闹着玩的。

  关于商业智能的需求,业界和用户就存在两种观点之争,为了说明两种观点,我把商业智能四个字拆开成商业智能两对,前者是商业观点,后者是智能观点。这也反映了商业智能需求驱动力的一个发展和变迁,从商业智能形成产业到目前,商业智能需求的主要驱动出现了三次变迁。

  首先是技术驱动,最开始只是觉得它是先进的技术,很多企业开始购买了很多这些产品,积极的通过技术的方法驱动这个技术在企业里面的应用。譬如引入查询与报表工具,多维分析工具来改些原来业务系统的报表以及开发一些分析型的应用。

  到后来我们称之为业务驱动,现在特别是金融行业,还有政府行业,他们的数据量非常大,基于数据的分析和研判实际上在日常业务流程的战术层次也有很大的一个应用的价值。前在很多行业里面,它的基本从业人员的素质已经非常专业化,比如说特别在金融行业里面,从业人员的素质非常高,因此他很多时候他的决策是在战术层面决定的,比如银行的客户经理负责信贷业务的话,很多时候是他客户经理就要决策,给这个客户相应的信贷的政策是什么样的,基本定制适合这个客户服务的套餐。面对这样一个情况,实际上我们看到很多时候是业务的一种驱动,满足一线业务人员每天做很多战术上决策的需要。

  再到后来是管理驱动,由于管理信息面的广度要求,就要开始建数据仓库整合数据了,大家可能觉得他是为管理服务的,但是我们认为在中国早期的bi建设当中,它没有真正起到这个作用,仅仅是给管理者提供了一些基本的报表而已。为什么会提到管理驱动呢,我刚才已经提到了现在的企业老总所面对的内外夹攻的双重压力,在这个情况之下,我们看到的是企业真正的意识到了这种管理的重要性,特别是现在金融企业,它面临很多管理上的改革,比如说中国的金融行业在这两年改革最多的地方,就是我们的信贷风险的管理,还有我们的相应的一些引进一些先进的成本核算的机制,还有绩效考核的机制,这些都是真正对管理从内在的改变。进而它反过来就会驱动数据仓库技术的应用。我们看到在以前,比如说我们做数据仓库的时候,我们会在中国的很多企业里面,认为它是一个可有可无的系统,只是说这个报表我早一点拿到,晚一点拿到而已,但是今天我们看到在银行里面所有的员工,他每个季度的奖金怎么发,都是数据仓库来支撑的绩效考核系统来实现的。

第四章回 商业智能的需求分析

  从这个变迁,回应刚才的我对商业智能的分拆,我们看到了一个很明显的趋势,就是目前商业智能需求的重点逐渐从智能转向商业,同时也因为这种我们和我们的客户对商业智能的理解的变迁,直接地影响了商业智能的需求形态,也必然对商业智能需求分析工作者提出了与时俱进,不断调整和修改需求分析方法的要求。

  在技术驱动的时代,商业智能的需求分析更多地是侧重在bi工具的应用,例如用报表工具来实现一些管理性的报表,用olap来实现一些经常性的数据统计与分析,用etl工具来替代手工编写代码方式的数据迁移。这个阶段的需求分析过程有非常明显的技术倾向性,这种项目往往有个前提,就是目标技术平台往往在项目启动之初已经敲定,需求分析师首先要非常了解目标技术平台的各项技术指标,并且非常小心地把目标用户的需求引导并且框定在这个目标技术平台的能力范围之内,这个逻辑是很自然的,也是无可厚非的。

  在业务驱动的时代,需求分析师首先需要非常熟悉目标用户的日常业务,商业智能系统比传统业务系统相比,需求的把握与定义是非常困难的,传统业务系统的流程是非常清晰的,类似银行业务的核心业务系统,诸如储蓄业务,对公业务,国际业务即使种类很多,而对于落实到具体业务的需求的时候,起码同一家银行是有一个标准的业务操作的流程的,不论流程多么复杂,所对应的需求总是明确的,可见的,用程序化的方式来表达也是简单的,而且作为生产系统,早日投产比完善往往是更具价值,在这个大前提是,花繁为简,稳定压倒一切是甲乙双方都认同的。而作为以辅助业务中战术决策的商业智能系统,首先要迈过的一个关口就是,在战术智慧上,系统的决策水平要起码高明于一个中等层次的业务人员的商业智慧,这样他才会觉得系统对他是有帮助的,回应刚才我所提出的,对商业智能需求的定义和控制过程事实上就变成了对人脑的控制过程,需求分析师如果不是一位该业务领域的专家,所能形成的需求分析结果能一次性地获得业务人员的真心拥护和认可无疑是天方夜谭,而在目前的bi界中,完全是从业务成长起来的bi需求分析工作人员凤毛麟角,实际情况往往是,一群技术功底还不错,脑子又转得比较快,能给客户一个良好形象的技术人员出身的人充当了bi需求分析师的角色,我就是一个非常典型的例子,这些人如果心态正确的话,会抱着一种对业务无知的谦卑感虚心地向自己的客户请教,并且仗着客户对技术莫测高深的敬畏,迅速地把需求结果框定为一个个本来就是客户手工在做的报表,当然也不排除通过向客户的需求学习,初步掌握了一些业务上的规律,把客户的需求提炼成灵活查询或者多维分析的模型。不幸地,就是这种需求分析方式也造成了我的报告开头所形成的需求怪圈,可以说,这种不幸的局面是先天性的,在东西没有实际做出来以前,无论是客户还是我们的需求分析师,双方所沟通的都是对方头脑里的想象,然后把这种想象用稍微直观一点的方式描述出来,这种表达的效果不管花了多少的细致周到的努力,实质上还只是一种纸上谈兵,或者俗称画饼,饼的模样是画出来了,饼的味道是无论如何也画不出来的,然而时间是不会等人的,工程师们迅速地照饼样动手施工,力求早日让客户吃上称心可口的美味,然而,交付的时刻往往是令人悲哀的,当用户第一口咬下去以后,能一口咬定就收货的用户几乎是不可能的,因为本来就是学生做出来的东西,有这样的结局是不足为怪的,于是就有接下来的不断的用户抱怨,不断的需求变更,不断的优化,不断的补丁,不断的忧虑和烦恼……

  目前,针对这种情况,一些大公司仗着自己的影响力,组织了一群技术专家经过多年的类似项目经验沉淀后,形成了一套所谓的模板,一则让bi需求分析师对于业务思考模式的学习和理解可以从客户现场退回到自己的公司内部,避免了露短的尴尬,二则,也试图用既成事实的行业标准的做法迅速而直接的影响用户的思维,业界内俗称,给客户洗脑,然而,针对个别企业的业务所分析出来的模板能推广,有一个预设前提,就是这种业务在全世界有一个可以普遍使用,而且有同质度非常高的标准成功模式,事实上,每个企业和人一样,是个性发展的产物,不是标准形成的产物,标准的推行本身就意味着企业的持续变革,这里也形成了一个悖论,持续的变革是否需要模板也需要持续的调整,然后模板的调整是否又需要持续的变革来配合,…… 本人对模板是认可的,而对模板的可推广能力是持非常怀疑的态度的。

  在bi领域,这个以优化为名的迭代几乎形成了一个没完没了的怪圈。这个怪圈的形成,给每一位曾为商业智能抱有共产主义理想的人冷冷地提了个醒,商业智能不是一个目标,而是一个过程,正如伟大的孙中山先生所嘱咐的,革命尚未成功,同志仍需要努力。

  第五章回 商业智能需求的出路

  一直到现在,可能各位觉得我对商业智能所持的是一种悲观的态度,这几年,我对商业智能的认识也确实出现了几次反复,从崇拜到失望,从激情蓬勃到理性回归,最后,我相信,商业智能需求必然走向的是价值驱动, 我相信,商业智能的需求经过多次否定之否定的螺旋式上升发展的过程后,商业智能的应用与企业价值链的优化组合是必然的趋势,只有把商业智能的需求和企业价值链的形成与提升结合起来,商业智能的实际价值才能得到真正的体现。

  正如前面的分析,各种内外因素的组合作用,使企业必然信息驱动为核心的生产和管理方式,在企业利润形成的整个价值链条中,信息使这条价值链从模糊逐渐走向清晰,将数据作为企业战略资产并且在数据质量方面继续投资,是使企业成为行业先锋的重要保证,运用商业智能的环境来回答诸如客户价值贡献度,地区市场差异,资本充足率,商品生命周期,成本与财务预算,定价策略,资金周转率等与企业利润的形成密切相关,商业智能把历史数据从数据监狱里释放出来,成为企业的一笔有形的资产。

  说到这里,已经到了我这次报告的尾声了,由于时间的限制,很多具体的点我都没有办法再深入展开了,我相信,商业智能从智能走向商业是一条商业智能需求走出困境的必由之路,我作为一个从事技术工作十二年,从一个很单纯的技术人员成长起来的技术人员,凭我自己的良心指出,技术至上的观点,不但会成为商业智能发展的桎梏,甚至会成为扼杀商业智能应用推广的无形黑手,所以,作为商业智能项目主导的这些需求分析负责人,首先,就要明确地树立的是做商业智能是为客户赚钱的商业观念,在和客户需求形成的过程中,把客户的需求引导向对客户有利而同时也对降低自身实施成本,加快投产速度也有利的角度,我从来不认为做报表和查询是一种身价的贬低,如果一份简单的报表或一笔简单的查询能为客户一年节省过千万的成本,避免一笔过千万的风险损失,一份报表就把客户对项目的全部投资都收回来了,这笔帐,我们这些技术人员应该学会帮客户算! 这样的商业智能项目,难道还会受到客户的冷遇和拒绝吗?

  最后,我们每位从事商业智能的业界朋友,有个很简单的问题我们问过了吗? 我想以这个问题作为我这篇报告的总结,请问到底什么是商业? 我想我的答案很简单,不过说了也等于什么都没有说,我想用这句香港人常说的口头语来作为我报告的结语:

  business is business!

2008年1月12日星期六

COGNOS经验摘抄一

用了将近半年的cognos,仍属入门级菜鸟,但是在使用过程中也颇有一些心得,将其整理并记录下来,希望对大家有所帮助

1. 在iqd中编写sql语句时,建议不要使用cognos的标准sql语法,因为这不仅会影响sql查询的速度,同时对sql查询的功能也有所限制,具体的实现的方法是直接将所有sql{}括起,这样cognos将不对花括号中的sql语句进行解释而是直接仍给所连接的数据库,用数据库自己生成最优化的查询计划。

2.关于iqd的写法,以下提供一个具体的模板,只需要依葫芦画瓢即可

COGNOS QUERY
STRUCTURE,1,1
DATABASE,DB
TITLE,IMR1.imr
BEGIN SQL
{select T1.C1 as c1,
T1.C2 AS C2,
T1.C3 AS C3,
T1.C4 AS C4
FROM SCM. T1

}

END SQL
COLUMN,0,C1

COLUMN,1,C2

COLUMN,2,C3

COLUMN,3,C4

3.对于相对固定不变的维表,最好是使用本地文本的格式如csv格式加以保存和维护,这样可以提高cube生成的速度

4.对于以时间为变化轴的数据,可以通过建cube group来按照指定的时间粒度进行增量维护

5.下钻路径应该根据维表层次的关系以及分析的需要进行选取,如果在同一维表中两个层次之间没有明确的继承关系,则应考虑将两个层次建在两个不同的下钻路径上

6.开发cube的时候,事实表中的数据应在保证不丢失信息的前提下尽可能的将粒度变大,这需要建立一个中间表,从源数据表中将聚合后的数据导入到中间表中,总之直接从源数据中提取数据建cube是不合适,应尽量避免


1. 对于多维报表模型,在开发环境下应存储为MDL格式而不是PYI格式,两种格式的区别在于MDL是以XML文本存储,保证了模型的移植性和可扩展性,但是在性能方面会相对差一些,因为每次生成Cube都要先将MDL编译成二进制的文件,而PYI则是已经编译好的,因此性能较MDL优,但是如果模型不是很复杂,两者的差别并不大

2.除时间维度外,其余维度中的category应设成always include,这样可以保证报表中有完整的分析方向,举个例子:

要分析所有客户中的男女分布,如果客户中全是男性,而将相应的category按默认生成include in need,则用pp打开cube后,只能看到性别维度中只有男性,没有女性。

这段时间又有一点体会,希望能为大家省去一些麻烦

1.Powerplay server 7 version 4的字体支持问题
从3.0 升级到4.0后,发现对粗体的支持有问题,发布的报表中如果使用了粗体,在upfront上浏览的报表出现了显示不正常的情况,主要包括:标签不能正常显示,报表中的数据不能正常显示,因此在4的版本下开发报表,应注意使用正常字体(这个问题,折腾了俺一个星期的时间才找到原因,5555)
2.报表格式的要求
为了保证报表有效、快速的显示,应在整张报表上使用相同的字体,并尽量避免使用图片等多媒体格式的文件
3.Transform中的多维模型设计
在维视图上,时间维在系统内部生成,并讲时间维放在维视图的第1列
在数据源视图上,将事实表放在最后
中间表的设计方面,在保证信息不丢失的前提下,尽可能通过聚合等方式,去除中间表中的明细数据
4.如果希望以时间为轴实现数据的增量更新,应使用cube group
5.如果要全部重新生成cube,应该将原有的cube删除后,再进行重建,否则会报错
6.如果维度比较稳定, 则尽可能的使用csv格式保存,对于渐变维或经常需要维护的维度使用iqd来获取
7.在pp中设计报表时,对于出现报表的列或行的维度,如果经常需要维护,则尽量使用subset,这样可以保证报表动态的更新
8.如果使用了宏来自动生成cube,产生报表,则在重新生成cube后,应该手工的保存mdl,否则下一次重新运行宏的时候,cube会生成失败(这个问题应值得注意)
9. 如果将其他环境下的cube放到当前环境中打开,如果cube中含有访问控制信息,则只有在当前环境下的Acess Manager中的用户类目录结构于先前环境下的完全一致,才能保证cube的正确打开, 可以先将前一环境下的安全控制配置文件导出为.lae,然后再导入到当前环境来完成这个工作


Cognos 企业级系列产品其实包括了两部分,一部分是ReporNet,一部分是Powerplay也就是人们常常提到的PPES,这两部分分别解决的是二维报表和多维报表的问题,同时在数据采集的机制上也是完全不同的,ReportNet采取的是对数据库做online查询,而PP则是在实现准备好的Cube基础上,创建多维报表,并支持钻取,切片,上卷,旋转等灵活的报表展示功能,前者的工作负荷集中在数据库上,而后者的工作负荷则集中在PPES服务器上。而两者的安装完全可相互隔离,他们在功能上是一种互补的关系,但是在物理上却毫无关系,对于Cognos产品的理解,我个人建议最好是先看看cognos自带的关于产品体系架构方面的文档,同时最好能自己亲手安装和配置一下,这样才能对其产品的结构有一个深入和全面的认识


数据库的导入
ReportNet自带sample数据库以及相关的工程文件
在导入模型之前,要将sample数据库中的表恢复至当前的数据库中,对于DB2,在..program filescognoscrnwebcontentsampledbdb2目录下有多个.tar文件,解压后可以看到有多个tabl?. ixf以及一个db2move.lst文件组成,其中db2move.lst是供db2move工具使用的列表, 而ixf文件中包含了相应的表的表结构定义和数据,使用db2move将表及其数据导入现有的数据库,命令如下:
db2move import -io replace_insert -u user -p password
如果提示单字节代码页集不相配的错误,可以自己建立一个批处理文件来使用import或load语句的forcein文件类型修饰符来强制对单字节代码页进行转换,如:
db2 connect to cogdb user cfep using cfep2004
import from tabl.ixf of ixf modified by forcein create into GOHR.BRANCH
import from tab2.ixf of ixf modified by forcein create into GOHR.EMPLOYEE
db2 import from tab3.ixf of ixf modified by forcein create into GOHR.COUNTRY_MULTILINGUAL
db2 import from tab4.ixf of ixf modified by forcein create into GOHR.COUNTRY
db2 import from tab5.ixf of ixf modified by forcein create into GOHR.GENDER_LOOKUP

将数据导入至数据库中之后,应对模型进行相应的修改,首先在crn中建立同名的datasource,并且在properties页中设置同名 datasource,schema设置为所使用的db2模式(大小写敏感),将type->interface设置为DB2,
即完成了对sample的导入工作

OLAP12条准则

Codd提出OLAP 12条准则来描述OLAP系统:
准则1 OLAP模型必须提供多维概念视图
准则2 透明性准则
准则3 存取能力推测
准则4 稳定的报表能力
准则5 客户/服务器体系结构
准则6 维的等同性准则
准则7 动态的稀疏矩阵处理准则
准则8 多用户支持能力准则
准则9 非受限的跨维操作
准则10 直观的数据操纵
准则11 灵活的报表生成
准则12 不受限的维与聚集层次

2008年1月7日星期一

[转贴]2007年度天涯100条爆笑评论

这是一片神奇的土地,每天都发生着令人不可思议的事情,仅以此文记录2007年缺失公信力的中国!

  1.一只河蟹横着爬过来冷冷道:“你找夹吗?!!!”

  2.《走进科学》终于揭开神农架野人之谜——原来这是一群买不起房的中国人!

  3.中国的新闻比小说还要精彩!!!

  4.在国外,死人的矿难叫新闻;在国内,救出来的叫新闻!

  5.功课成绩全A,应聘的时候也竞争不过人家一对C!

  6.两样东西阻碍了中国男足冲出亚洲——他们的左脚和他们的右脚……

  7.为了做公务员,我生了领导的儿子!

  8.派出所是中国最大的反对党培训基地!

  9.城管大队长猝死在街头——狗都累死了,可见统治者残忍到什么程度!!!

  10.售楼大厅里,一位怀抱巨款的母亲哭了。我发自内心的觉得应该好好感谢政府,没有政府的英明决策,哪来的人间这般真情!

  11.他们说我钉子户是刁民,我就骂他们是刁官,因为只有当年日本鬼子在中国才说刁民和良民。

  12.威斯特年画——唯一登上美国《科学》杂志的中国年画!

  13.数据显示,2007年中国男性占全国总人口的52%,女性占43%。

  14.政府说的话就像尼斯湖水怪一样无所谓真假;政府的信用就像我的贞操一样稀罕但不值钱!

  15.美国自南北战争后就没有奴隶了,黑人奴隶变成自由人和国家公民;而在新中国的山西黑砖窑,却把自由人和国家公民变成了黑人奴隶!

  16.据国家统计局统计,2007年中国同比没有增长的有:1.工资;2.空气。

  17.什么节目充满了欺骗谎言却极受广大人民群众的喜爱?答:新闻联播!

  18.2007年中国股民真实写照:辛辛苦苦两三年,一夜回到解放前,宝宝飚泪把戏演,南海剧组狂搂钱!

  19.开发商买不起人民群众的房子就让法院强制执行,那么人民群众买不起开发商的房子是否也可以要求法院强制执行?

  20.商场:不卖镇坪腊肉!(理由:纸虎原产地,假货自然多!)
   企业:不招镇坪工! (理由:一方水土养育一方人!)
   大学:不招镇坪生! (理由:考试作弊,头号嫌疑!)
   部队:不招镇坪兵! (理由:连纸老虎都怕!)
   好男:不娶镇坪女! (理由:买个充气的,强过纸板的!)
   好女:不嫁镇坪男! (理由:除了嘴硬,哪都不硬!)

  21.嫦娥一号发回来的照片不是假的——因为市面上还没有发现月球的年画!

  22.国家统计局解释说:数据出现偏差并不奇怪,因为1个亿万富翁配上你们99个穷光蛋,平均下来中国人人都是百万富翁!

  23.世界上最可怕的事情不是生死离别,而是2008年你赶了一群猪浩浩荡荡地去北京换房!

  24.你们也不能太侮辱周正龙的智慧,至少他自己没顶片树叶,然后宣称自己是华南虎!

  25.高昂的医疗费用使老百姓得病直接进火葬场的可能将在三年内实现!

  26.从许霆多取了17万就被判无期徒刑,我们可以得出结论:中国只有法官,没有法律!

  27.政府动辄说:“我们也难啊,得养活十三亿人。”可问题是我们十三亿人养着政府还是政府养着我们???

  28.汽车、房子、民主、自由,这些现在都已经不是最重要的了,对于绝大多数中国人来说,怎样能在和谐社会下填饱肚子,这才是第一重要的~

  29.究竟是通货膨胀了,还是政府开始抢劫了?为什么我们这么努力地工作却过得如此艰难?终于明白大宋京都司令部司令员林冲,这么优秀的公务员为什么都上梁山了!

  30.CCTV1《晚间新闻》:大陆10月物价上涨6.6%,群众一致表示“对生活影响不大”;CCTV4《海峡两岸》:台湾物价增长4.5%,民众大叫“活不了了”!

  31.民主孕育幽默,独裁引发讽刺!

  33.世态炎凉鸡最懂,人情冷暖鸭先知。

  34.矿难在检讨中继续,楼价在控制中上升!

  35.都是中国人,不用讲素质!

  36.看了CCTV,觉得中国了不得;上了天涯杂谈,觉得中国不得了!

  37.英雄不问出路,流氓不看岁数!

  38.有奶不一定是娘,但有钱一定是爷!

  39.天亮睁开眼,还活着,真好;天黑闭上眼,能睡觉,值了!

  41.在中国凡是带“民”字的都落不着什么好——譬如民工、农民、民营、股民……

  42.中国上半年财政收入比去年同期增长32%——掠夺之疯狂可见一斑!

  43.现如今有钱的不如有权的,有权的不如有枪的,有枪的不如拿斧头镰刀的!

  44.好人苦不苦,扶个老太四万五;好事累不累,助人为乐是犯罪!

  45.政府不应该把个人所得税起征点订在2000,而是应该把中国最低工资订在2000!

  46.在中国,法律面前人人平等——关键在法律背后就不好说了!

  47.大陆的高官全世界哪个国家都可以去,但老百姓不一定哪儿都能去;台湾的高官全世界哪个国家都不能去,但老百姓哪儿都可以去!

  48.政府辟谣的事9.9成是真的,所以宁可相信谣言也不要相信政府,这是生活在现在的中国人的经验总结,血和泪换来的真理!

  49.在中国,网络代替了民主国家反对党的作用!

  50.(天涯不支持ascii码,先空着)

51.方丈说:“出家人不打诳语,相信CCTV还不如来我这里烧香拜佛。”

  52.杭州县长说:“晚上带你去看帝国主义的侵略!”(注:伟大领袖毛主席教导我们:帝国主义的侵略都是赤裸裸的!)

  53.山西洪桐县矿难105人遇难——向中国探地工程殉难的勇士们表示沉痛地哀悼!

  54.东莞农民骂道:“我们能养政府,为什么就不能养猪!!!”

  55.啥叫韩国人?就是牛逼的都是他家的!啥叫印度人?就是他家的都是牛逼的!

  56.明年是否真的存在北京奥运会,这事儿还得让陕西林业厅的请专家来鉴定一下!

  57.上级领导视察浠水县税务局,见到操局长的女秘书关心地问:“今天高潮来了没有?”

  58.气象专家做客电视台辟谣说六月的北京绝对不可能下雪,第二天猪笑着打滚道:“别污辱了俺的智商!”

  59.现在广东的胖人都不敢出门了,因为一出门街上就有数不清的眼睛绿油油地盯着他身上的肉!

  60.古人云:善有善报,恶有恶报。彭宇案后父母教育孩子:善有恶报,恶有善报,不是不报,南京法官未到!

  61.语文考试应该取消作文,因为我们人生第一次撒谎都是从作文开始的!

  62.要玩一夜情你也得找对地方啊,有道是劲舞团里寻小姐,可没听过谁玩跑跑卡丁车能搞出一夜情的!

  63.问个问题,中国有没有哪个领导人的亲戚不当公务员或者不开公司?

  64.随着肉价再次上涨,以前开玩笑说猪的“四大理想”中的“全国人民信回教” 就快要实现了!

  65.这次北京奥运会,安全套的尺寸一定要齐全!

  66.弘扬某党办事雷厉风行的超短篇小说:党员:有发票吗?妓女:有!党员:走!!
  
  67.71张照片充分揭示华南虎成为超稀有物种的原因——吐着舌头正面被人拍了半个小时都不带换个姿势的老虎,它不灭绝谁灭绝!

  68.南京法院的逻辑:赖宁去救火是因为那火是赖宁放的,雷锋帮老大娘买票因为大娘的钱是他偷的,98年抗洪是因为洪水是解放军泄的!

  69.彭宇案对社会还是有很大贡献的:以前大家如果没有见义勇为、帮老扶幼,事后难免会良心不安,自我折磨。现在不用了,很坦然就可以了~为什么?难道法院说的还会有错?

  70.张纪中版《西游记》里的天兵天将将在全国各地城管中进行海选,因为城管队员不论是形象作风,还是战斗力都非常有震慑力,非常适合演招之即来、来之即战、战之能胜的威武之师、文明之师!
 
71.山西——中国矿难事故的形象代言人!

  72.中国的肯德基是用来上厕所的!

  73.股票赔的只能扮超人出去打劫了!

  74.XP不发威,你当我是DOS啊!

  75.比谣言更可怕的是对言论自由的剥夺!

  76.中国的国旗和煤是红色的!

  77.爱她——就要喝可乐!

  78.这个世界上对姚明包夹最紧的,莫过于叶莉!

  79.她哥哥是黑社会咋了?我靠,你丫就不会入党啊!

  80.中国只有骗子是真的,因为只有假的才永远假不了!

  81.中国真的进入法制社会了——过去政府宣扬亩产万斤还受到领袖表扬呢,而现在自己造个纸包子新闻就要被判入狱了。

  82.封建社会权贵们用“天子犯法与庶民同罪”的空口号来愚弄百姓,新社会无非换了个口号——“法律面前人人平等”!
  
  84.啊,美丽的三峡大坝,感谢政府给重庆装了一个这么大的天然空调,只可惜砖家们把空调散热方向装反了!

  85.没了天敌,洞庭老鼠泛滥成灾;那没了什么,中国贪官污吏才泛滥成灾?

  86.和平年代能让一个地方(太湖蓝藻)的居民受到生命威胁,这在任何一个渴望和平的国家人民眼里都是不可思议的事!

  87.把陈良宇开除党籍也太欺负人了吧!你们党员杂碎就往我们群众队伍里推呀,和着我们群众就是藏污纳垢的地方啊!你经过我们群众同意了么?他本来是公仆,这么大的罪怎么反倒变成主人了???

  88.正常的事发生在正常的体制中或不正常的事发生在不正常的体制中都是正常的,正常的事发生在不正常的体制中或不正常的事发生在正常的体制中都是不正常的!

  89.傻逼应该是这样的:一个丑陋的男青年,穿了个两块钱的耳环,头顶用刺鼻的东西把黄毛竖得高高的,然后耳发和后颈留得又长又脏,一身假NIKE,手上一个NOKLA N73,手机的破喇叭里用最大音量播放着《求佛》,然后坐在公共汽车上一边抽烟一边对身边站着的孕妇老人熟视无睹,接着把嘴里的瓜子壳吐在地上,然后把瓜子袋扔到窗户外面,嘴里脏话连篇,然后盘算着回家去看个辫子戏!
  
  91.我生活在一个由封建阶级统治下用资本主义生产方式发展的人权状况比美国好五倍且被定义为社会主义国家的奴隶制国家里!

  92.“和谐”之所以成了一个讽刺,在于执政者口号喊得和现实反差太大了!

  93.组织之所以不可战胜,是因为组织不是人!

  95.对制造纸包子新闻的记者判刑并不是因为他侮辱了中国新闻记者的名声,而是因为他玷污了我国广大无良商贩们的智慧!

  96.恶意讨薪、恶意取款、恶意打工,只要和老百姓有关的都是恶意的;合理贪污、合理违法、合理拆迁,只要和政府相关的都是合理的!

  97.不要去见义勇为——这样本来就不是很好的社会风气就会更糟!

  99.我出生在中国,死了葬在中国,真是祸不单行啊~

  100.不知道我们看了这些该哭还是笑,但这就是我们天涯人眼里的2007:盛世出国虎,虎啸振国威。国危多妖孽,群丑闹中华!

32、40、83、90、94、98无法显示,请参见
http://cache.tianya.cn/techforum/content/14/738835.shtml

2007年8月29日星期三

one-to-one的效率问题,用one-to-many来替代?

由于最近在把以前的一个设计移到hibernate上来,所以需要用到one-to-one,因为在以前的设计中需要用到在一个主表中对于多个子表的主键关联,所以一开始就想到了one-to-one的应用,觉得这样解决不但不会引起以前数据设计的改变,也能够很好的利用hibernate所带来的OR优势,可是当实际使用的时候发现,在插入数据的时候可以有选择的在任意子表中进行插入,所有的结果都在原来的预期之中,但是在查询的时候,比如说只查询主表中的内容

From tableMain

仅仅执行看起来十分简单的一条语句,你所期望的是他紧紧查询T_MAIN这张主表,可是结果确实hibernate通过多个外连接将所有的子表一口气的全部查询出来

select * from t_main main outer join t_sub1 sub1 on main.id = sub1.id outer join t_sub2 sub2 on main.id = sub2.id...

如此的效率绝对让你头痛不已,不仅如此,如果你通过首先获得子表t_sub1的某个主键ID,然后通过这个主键查询出子表对象,在关联至住表,同样的情况又会发生,又会生成类似的SQL语句,这样一来看来对于这个设计应用one-to-one本身就是一种错误,是这样吗?

或许有人认为我们在每个one-to-one中加入lazy="true"这个属性会杜绝上述情况的发生,经过笔者的证实即便你加入了lazy= "true",也不会带来任何的改变;又或者在hibernate.config中加入fetch depth属性以及在每个关联中设置outer-join="false",这些都不会引起本质上的变化,加入outer-join="false"其实结果只是将原有的outer join语句改变成多条sql语句而已,并没发生什么本质变化,反而效率更低了。

该怎么办呢?我们先仔细研究一下one-to-one的概念,one to one代表一对一,在一般的模型中很少会遇到one-to-one这种概念,因为他十分强调一对一的概念,就好比一个人他只有一个身体和一个头而已,头和身体是十分好的例子,因为有身体必定只有一个头,而且说到了身体必定要说头,就好像看了某个女孩的身材必定想知道她的长相如何(-_-),所以在这时我们使用one-to-one,因为这种一对一的关系是很强的,而且从对象中取得body必定会取得他所关联的head,这样的情况下使用outer- join是十分方便和有效率的,因为它使用了outer join查询从而避免了两条到数据库的查询语句,而且在这种情况下也只需要在body_hbm.xml中设置一个one-to-one即可,所以在这种确实是一对一而且在主表中一对一的关联个数(即主表中one-to-one标签)十分少的情况下,使用one-to-one是一种很不错的解决办法。

如果一个主表会对多个子表都进行one-to-one关联呢,就像我们一开始遇到的这种情况,比如你不仅仅只想了解那个你中意的女孩的身材和脸蛋,而且还想知道他的学历,身世等等一切,在这种情况下,如果我们都是用多个one-to-one在主表中的话,那情况正如我们一开始看见的,是十分可怕的,该怎么做呢?不妨考虑一下使用one-to-many,什么,many?一开始听到many这个词的时候,我也觉得挺惊讶的这明明是多个一对一的关联为什么要用到many呢?其实many并没有一定要说是大于一的,你就只在它的many中存在一个关联它有能乃你何呢?如果用到many的话,我们就需要改动数据表的设计了,在每个有关连的子表中加入一列main_id代表主表中该记录的主键子段值,只需要这样子改动就可以了,这样所带来的效果绝对是值得你这样做的,然后我们就按照以往的one-to-many来设计就好了

在body.hbm.xml加入(一到head的关联举例,其他的关联按照这样的格式添加即可)





在head.hbm.xml加入


行了,经过上面的改动我们就摆脱了查询时多个outer-join的困扰,只在需要的时候才对子表进行查询,因为设置了lazy="true",所以一切的一切都在我们的预料之中,我们如果希望获得body的话hibernate绝对不会把它的head 也查询出来,节省了查询是所需要的负担,除非到了我们十分需要head的情况才会进行关联查询,获得所需要的head结果。

所以由此看来在one-to-one这种一对一的关系不是很强的情况下,或者是在一张表中存在多个one-to-one的情况下,使用one-to-many来代替one-to-one不失为一种不错的做法,当然更重要的良好的数据库设计,hibernate毕竟只是末,千万不要本末倒置。