[更新至20080725新增BIEE初级前端与后台]项目经验分享了哦 上海, 项目, 经验, 学校, 目标

chrisyang

首先向各位看官报个歉，4月底回了趟老家昨晚才回上海，让大家久等了，把大家的口味调得老高，真是不好意思。


    去年6、7月间，我一直在思考一个问题，我该怎样规划我的未来，我的目标是什么，在哪里，该怎么走，我该怎样为我的人生去奋斗，相信这是一个让许许多多的人都感到非常困惑的问题，而这时我已来上海整整一年。学校的生活可以说是丰富的，精彩的，惊喜总是不期而遇的到来，因为我不但学到了学业知识，更是因为结识了一帮志趣相投努力上进的朋友同学，才会使得我渐渐在这个苦恼的问题上获得了答案。在校的一年，也就是在这一年，因为专业的缘故我了解了ERP，我开始认真的学习这个行业的相关内容，逐渐被这个行业的魅力所吸引，到后来，确定了把自己努力往BI领域靠拢。
    9月底，很有幸地我加入了一个BI项目团队，开始真正的为自己的理想开始追逐，似乎一切都那么如意。
    但是很快我就尝到了工作现实的苦头，因为毫无工作经验的我很难把握工作的节奏，很多事情都不能够顺利完成，离开了学校的书本，一切对我来说是如此的艰难，就连出现的最简单的问题都很难陈述清楚，发送出去的邮件都好几次被退回来要求重写。本来工作就要求团队合作、快速高效，PM安排的事情一个接一个的，但是项目进度由于我这一环脱节延误了不少，一下子我感觉被压得喘不过气来，感觉工作超级艰难。责备是理所当然，但是值得庆幸的是PM还是很不错的，前一个月多次跟我交流，询问我手中事情的难点，帮我分析事情的关键，教我如何处理，点点滴滴我一直铭记在心：在团队项目中并不是你一个人在战斗，项目组就是一个拳头，遇到困难一定要迎面出击，不清楚的问题一定要及时跟团队沟通，有了问题藏着掩着是行不通的，出了问题是好事，去解决不就好了。
    项目分解开来主要是这么几块：ETL+BIEE后台模型+BIEE前端报表+权限，可以说整个项目就是围绕BIEE展开的。
    我进入项目组的时候ETL已经基本完成，BIEE的模型也初步成型，PM安排我首先熟悉ETL，包括对ETL的维护。所有后台的数据都是通过ETL程序从已有的ERP环境抽取到BI的数据库里来，每天夜晚进行更新。这个任务对我这个新手来说是再好不过的了，ETL是BI项目的基础，了解了ETL数据的来源、走向，对后面数据在模型在BIEE的搭建起到了关键的作用。ETL主要是分成两个部分，首先是原封不动从ERP截过来，然后再在BI的数据库把数据按照BIEE数据模型的要求进行转换。数据模型是比较常见的维度+事实表，怎么样理解维度+事实表呢，就拿简单的销售数据来数，我们可以把与销售相关因素如时间、公司、客户、销售员、产品看等几个维度，而销售的实际数据如金额就当成是一个事实，即一个分析项。从而建立销售事实表与时间维、公司维、客户维、销售员维、产品维通过外键进行连接。维度的特点就是变化较小，也就是更新量比较小，而销售的数据是变化比较多的，一个公司每天都会产生N多的销售数据。ERP的销售数据最底层的就是line上的信息，但是BI的报表，公司可能关心的就是某个时间段（点），某个客户对某个产品的销售情况是个什么样，具体就是卖了多少，卖了多少钱。这就要求数据从ERP截过来后要做转换，按照所关心的维度进行聚合，聚合后的数据就是多维度的、最底层的数据了，这样保存在BI的数据库里就已经满足报表数据的要求了。业务人员根据需求在查看报表的时候再对这样的数据进行更高级的聚合，比如一个产品，客户A今年与去年同期的销售情况对比，或者查看某个产品去年某个时间段内不同地区的销售走势等，这样就能够对这个产品的市场进行调整。基础数据聚合是ETL里用得最多的技术之一。ETL程序的异常处理也十分重要，因为数据是每天在更新，就算程序写得再好，也会有碰到ERP调整或者其他原因导致BI数据库的更新出现问题，所以异常记录显得尤为重要。通过异常记录，就可以迅速的查找到数据更新问题所在，及时的调整好ETL。ETL里数据的更新主要是使用merge的方法，如果对源数据了解不清，经常会出现报源数据缺失稳定行的错，这是因为源数据如果在merge的on条件里存在多行相同的数据，就会造成无法与目标数据进行匹配，目标数据不知道到底要跟哪条数据进行匹配，这就是数据的“不干净”导致的。虽然说转换好的聚合数据，要比ERP的基本数据行数要少很多，但也有可能是上百万级的，在按维度拉报表的时候，再进行复杂的多表多维连接聚合操作，相应时间依然不能满足业务人员想要达到秒开的效果。这就可以考虑把这种经常查询的分析项（通常是dashboard上展现的多个分析项）做成MV的形式，并每天刷新，一切都是为了报表的展现服务。
    BIEE后台数据模型很关键，直接关系到前端报表分析项的使用。BIEE Administrator Tool 把数据分成三层：Physical层、Logical层、Representation层。Physical层就是把BI数据库里有用的的表、视图导入进来，然后按照事先定义好的维表与事实表进行连接，基本上把维表上的主键与事实表上的外键相连，一个事实表需要把它能搞到达的所有维表连接。然后就可以把数据对象添加到Logical层的Logical table和Dimension里。其实从这里开始才真正区分什么是事实表，什么是维表。Logical table可以由多个目标表组成，这些目标表一定要有统一的维度。建立Dimension的时候要注意的一点就是，在建立时间维的时候一定要让Administrator Tool 知道这个是时间维，有一个标识一定得勾上。 为了让不同职责的业务人员在自己的范围内查看报表，可以在Logical层建立多个不同的主题区域，每个主题区域由与主题的内容对应的事实表以及维度构成，方便用户操作。Representation层的数据就是在web上展现的数据，一般就是Logical层的简单删减。关于模型的搭建我会逐步补充，内容精彩，值得期待。
    后面我还会讲BIEE前端报表及权限的内容，今天实在是太困了，先睡了，随后再来...    ^_^


-----------------------------华丽的分割线-----------------------------

    话说上回鄙人答应讲解BIEE的一些设计问题，总觉得零零散散的讲不能得到大家的信服，所以鄙人毅然决定在接下来的一两个月里跟大家共同探讨一下
BIEE这个玩意到底是个啥，如何把玩，好不好玩，怎么玩才玩得转，经不经玩...带着这些问题，让我们共同由浅入深的逐步揭开它的神秘面纱。
    好！各位看官，follow me，君请看：
    小弟不才，如有不得之处还请多多包涵，还请各位看官得饶人处且饶人呐，同时也欢迎专业人士前来找茬，再次感谢各位的对鄙人的厚爱，谢谢。

PS:我之所以没有用数据库demo实例数据，是因为那些数据不够贴近真实的项目要求，不过我可以说明一下文中数据格式
1.时间三张表：D_TIME_DATE（含年、月、日），D_TIME_MONTH（含年、月），D_TIME_YEAR（仅含年）
2.组织公司信息：D_ORG
3.客户信息三张表：D_CUST、D_CUST_SITE、D_CUST_SITE_USE（熟悉订单的朋友一定知道这三张表的含义）
4.产品信息：D_PROD
5.销售信息：D_SALES（除了销售数量和金额外，其他字段都是跟以上4类表相关联的外键）
这些表结构都很简单，需要的朋友可以前来跟鄙人私下交流


来，让我们的板块更加火爆吧


[ 本帖最后由 chrisyang 于 2008-7-28 18:15 编辑 ]

zhzhs007

楼主什么时候能贴出来啊

chrisyang

5.1前后吧

ahutguo

:/xia :/xia 别让我们等太久哈~~

jessie

期待，期待，期待。。。。。。

QIAOWEINIHAO@16

在我整理出来之前哦！！

yuswallow

期待中！

panlinp

期待啊

bridge243

期待~~

Michael

期待~~

振振

期待......

静雨

^&*^(&*(&()%^$%^

[ 本帖最后由 chrisyang 于 2008-4-26 22:48 编辑 ]

hserp

期待中!!!

bhbb2000

密切期待兄弟的大作！

quaker

占个位置等着先

likeye

等待楼主资料
现占个坐谢谢了

sunnick

先感谢了!!后天就5.1了,在家仔细拜读. 期待...

jxxy5410

排队等候………………

mzwilson

加油啊，时间快到了

chestnut

赞一个！

gaoqun2

占位期待一下

lcbao76

期待中......

freeya

欢迎进行项目经验分享，学习...