我也来作个比喻

模型设计  -> 大厦的设计图纸

数据        -> 砖瓦、材料

实施人员  -> 施工队

ETL      ->  建造大厦的过程

BI TOOLS -> 装修

Data Ming ->精装修

DW  -> 大厦

业务人员 -> 业主

客户IT部门 ->小区务业

格式上有点乱..大家看时,仔细区分一下..

另:经与刘庆的讨论,觉得...BI TOOLS

生成的报表\图表\分析 -> 装修....这个好一些..

记得Kimball也有个类似的比喻，不过是用一个餐厅来比喻的，原文不记得何处，大意如此。
 
餐厅的后厨房就是数据仓库构建的地方，相当于IT部门。蔬菜、肉类，各种调料当然就是数据，他们从市场上买回来，经过清洗、拼盘。
 
而餐厅前面的大堂则对应各个业务部门，顾客就是发出种种需求的业务人员，"我要土豆烧牛肉"，"我要一份小鸡炖蘑菇，哦，不行，现在禽流感，改成珍珠翡翠白玉汤吧"。
 
根据这些需求，厨房里的大师们希里哗啦，整出一盘盘的。当然，除了味道要正，色泽也是不能差的，不然让人没了食欲。也就是对应着数据质量和展现都不能差。如果，厨师在每盘碟子上贴上个标签，"x号厨师为您服务"，那是他们元数据做的不错。

比较一下Kimball和Davidjiang的比喻，觉得Kimball的比喻在范围上更贴切一些:)

建造大厦与业主装修相比更象是建造数据仓库和数据集市的关系。

如果沿着这个比喻继续引申......
 
大厨们其实就是报表开发工程师了，顾客每个人的需求不同，每盘菜都得现炒现卖，同样是鱼香肉丝，有人喜欢咸一点，有人辣一点，有人要放胡萝卜丝而不是笋丝，这叫需求的框架性和不定性；好比报表中不同的样式和风格，以及不同的权限；

服务员要充当需求分析员，不是虽然看上去顾客是可以任意组合的，但服务员和客人说“熊掌炖人参会让您鼻血长流，您要是没地泻火的话还是吃萝卜炖排骨合适一些”，“鸡肉+芝麻，同食严重会要命......”，有时候顾客不知道吃什么，就得推荐“看您肾虚，吃点王八炖XX补补肾呗......”

顾客是上帝，不是那么好伺候的，OLAP分析等于让客户自己下厨房，反正就这些料，你想自己咋炒就咋炒吧，服务员说：“我们这有Essbase牌煤气灶和Brio牌炒勺给您用......”

听说八角茴香中的某些化学成分能防禽流感，顾客说我要清炖一斤八角茴香防禽流感，这就是对数据挖掘的期望......

菜谱是业务元数据；原料采购单是数据源元数据；烹饪方法是ETL元数据；厨具说明书和餐厅服务指示牌是系统元数据......

DavidJiang 的比喻从DW实施过程来看是很形象的，比如我们这些"施工队"每天就是与砖石水泥管材等东西打交道，还得与业主，物业管理，监理沟通（不是件轻松活），还得设计图纸（尽管这应该是由设计院来干的活），使用这样那样的低级高级工具来建造大厦，大厦建设完后还要负责根绝具体业主的个性化需求来个精装修，所以这个施工队还真不是普通的施工队，尽管从理论上职责划分应该更明确些，更细分为好，但是"包工头"们为了成本控制的考虑往往却是如此的一人多职责。
  
另外模型设计----〉大厦图纸设计  那么模型的元数据可否比喻为图纸上的线条符号以及具体数据。ETL设计----〉施工图纸设计；ETL元数据-----〉施工图纸上的线条符号等数据

请大家回帖子的时候多表达一些实际的内容，好吗？这样的帖子以后还是少发一些吧，免得浪费大家的宝贵时间，不是吗？如果觉得没有什么东西可写，也可以摘录一些网上的好文章给大家分享一下，不要为了写文章而写文章，我主张厚积薄发，有感而发。我觉得大家可以在这些方面寻找一些写作的素材：

1，最新技术分析；

2，疑难问题解决记录；

3，业内重大事件分析；

请大家多思考，既然是BI论坛，也请大家重视帖子的质量，不要成了灌水的论坛，不妥的地方请大家多包涵，为了大家共同的进步，请认真维护这个论坛的良好技术氛围。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友