每每与BI同仁谈起做BI项目时，一个每谈必论的话题就是：BI人，要不要精通业务？
而每次讨论的结果是，绝大多数BI人都会同意：BI人，必须精通业务。更有初入行或刚毕业的新BI人，更是因为“觉得”自己尚不精通业务而纠结ing，焦燥ing，每日惶惶然，惴惴然。
对我自己而言，在刚接触BI的时候，我也是如此的。
眼看世界末日将至，虽不至于万念惧灰，但仍是多了一些思考，恍惚之余，忽然之间，夜空若有灵光闪现，似乎有所感悟，事实似乎并非如此，遂打坐结印稍做神游，俄尔长身而起，振臂高呼：
我错了，你们也全错了。BI人，放下你们背上的包袱吧，你们不需要精通业务。轻装上阵，只须做回你们的本行，就万事大吉鸟。
你！本来就是专家。
我老婆以为我疯了，我不跟她解释，反正跟她也解释不通。
我只解释给你们：
在解释之前，我希望每个人都是了解关系型数据库相关概念的，因为我们现在做BI项目使用的元数据基本上都是基于关系型数据库的，比如SQL SERVER, ORACLE，DB2等等等等，当然各数据库系统有各自自己的特长和差异性，但是核心概念是一样的，就是一个二维表结构（后来的XML实现了多维，极大地简化了使用二维结构来表示一个多维概念的复杂性），这是题外话，跳过。
首先，大家想想，我们的BI项目是怎么开始的。前面那些该死的售前是怎么忽悠客户的；又是怎么胡乱答应客户要命的需求的；还有，客户乱七八糟的数据是怎么填进数据库的，我们先不管。我们只假设从现在我们已经有了一个有足够元数据的数据库开始。
现在，我们拿着一个里面装有一大堆各种各样元数据的数据库，我们要开始做BI了。
大家想想，我们的BI项目是怎么开始的？
对，首先就是数据建模，根据不同的主题建立不同的数据模型，
然后，生成cube（如果需要的话），
然后，做固定报表，
然后，培训客户用户自定义分析（如果需要的话）。
我们都知道，最最最重要的就是数据建模，数据模型的好坏直接决定项目的成功与否。
可是我们数据建模是怎么开始的呢？对，就是拖入那些乱七八糟的数据表，然后建立关联关系。
这时你要说了，对，这里，这里，就在这里，你不懂业务，你怎么建模啊?
没错，我不懂业务，我仍然能给你把模型建立起来，你信不信？
可是怎么建呢？
做过开发的人都知道，任何应用系统开发时，都是业务人员提出需求，然后开发人员分解需求，然后定义相关的数据结构，然后再在这个数据结构上开发应用程序。
此时，开发人员定义数据结构的时候，一定会确定数据之间的相关关系，这个就是业务逻辑（事实上，在一个数据库应用系统开始建立之这前，它的业务逻辑就已经包含在里面了，只是我们没有静下心来去理解那些开发的神人们的思想而已）。
这里的“相关关系"，就是我现在建模要用的。
说白了，这个”相关关系“，就是表的主外健关系，只要有了这个关系，就把表关联起来了。
不管是星型模型，还是雪花模型，莫不是通过这个关联关系连接起来的，
我们平时说的master-detail,primary-related等等，都是通过这个关系确定的。
所以，我不需要知道任何业务知识，只需要知道那些基本关键字段的意义和关联关系，我就可以把模型建起来。
表与表之间的关联关系确定后， 其他的就好处理了。
所谓维度，实际上就是几个孤独的并行的字段。
然后是层次，实际上就是上面那几个老死不想往来的字段通过master-detail或primary-related关系连接的下级表的关键字段。
然后是指标，这个好理解，只能是数字类型的，是要显示的结果。
还有所谓粒度，就是从不同的层次对指标进行汇总计算。
主题就更容易理解了，就是把相关的表拖到一起，因为前面已经建好关系了，所以直接拖进来就行了。
总之一句话：
剔掉肉，只剩几根骨头，把骨头接起来，模型就成了。
忽略掉那些描述字段，比如name,description之这类的，只留code,id,然后根据code和id的关系，把他们关联起来，模型也成了。
就跟我前面说过的，事实上，在一个数据库应用系统在开始建立之这前，它的业务逻辑就已经包含在里面了，只要我们静下心来去理解那些表和字段，业务规则自然了然于心。
模型建好后，其他的一切，你懂滴。。。
所以，BI人们，请坚定你的眼神，不要被那些眼花缭乱的业务规则打乱你的心，做好你的IT本行，向客户索取尽量完整的数据库设计文档，认真分析好表结构，其他的，一切尽有可能。。。。。
收起