数据仓库工具箱（第3版）读后感第一篇
年后上班就在亚马逊下定了此书，结果亚马逊要15后才发货，收到后周末刚拜读了前两章，感觉翻译极差，语句晦涩难懂，没看过前两版，不知好不好，但建议有能力的，还是看英文原版吧。
凑个字
凑个字
凑个字
数据仓库工具箱（第3版）读后感第二篇
前几章理论的东西太多了，问题是中文版的翻译真是太差了，句子都不通顺，谁能告诉我，这句话是什么意思 ‘也许您一直期望粒度由对事实表主键的传统生命描述’。。。翻译差 翻译差 翻译差 翻译差 翻译差 翻译差 翻译差 翻译差 翻译差
数据仓库工具箱（第3版）读后感第三篇
读了前3章，我能看懂翻译的句子就不错了，前面的理论性太多，读完对各个理论没有特别清晰的认识，直接从案例开始了，但愿案例能说的明白点。凑字，凑字，凑字，凑字，凑字，凑字，凑字，凑字，凑字，凑字，凑字，凑字，凑字，凑字，凑字，凑字，凑字，凑字，凑字，
数据仓库工具箱（第3版）读后感第四篇
无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语无语
数据仓库工具箱（第3版）读后感第五篇
翻译的太差了，感觉像是谷歌翻译机翻的，选择译者的时候出版社能不能考虑一下翻译水平，全是中文，一个看不懂，感觉翻译的人根本没有做过数据仓库相关工作。两颗星给原著，真的很经典，在想办法去搞英文原版和第二版，这个第三版的中文版坚决不建议看，看起来进度太慢，很难理解原著作者要表达的意思，这个翻译绝了
数据仓库工具箱（第3版）读后感第六篇
The lengthy list of date columns captures the spans of time over which the order is
processed through the fulfillment pipeline.
日期列的长列表获取订单通过整个流水线处理过程的时间范围。
数据仓库工具箱（第3版）读后感第七篇
这么好的书，翻译成这样？没人监管吗
这根本不是专业度的问题，一个个句子读不通，一句句都要去查英文版。
很多时候主语谓语宾语都是乱序的，这是在用方言表达吗？
译者序：写到力求“信、达、雅”？都没达到语法正确的最低标准，何来信达雅？
这不是赚快钱，不是求名声，是百万中国读者的学习材料。这么经典的著作就被毁了！！！
数据仓库工具箱（第3版）读后感第八篇
9.5.1
采用刚刚描述的专家表方法。
我晕了，这啥意思，看原文，原来是
采用刚刚描述的支架表方法。
专家？支架？大悟，原来作者用的是拼音输入法！
字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数字数
数据仓库工具箱（第3版）读后感第九篇
看中译版，翻译质量太差，每个字都认识但连起来就是读不通，感觉语文不够用了
看英文版，自己语法太差，每个单词都认识但连起来就是不明白意思，感觉英语不够用了
看来还是得好好学英文争取将来有能力直接看原版。
计算机这行当，至少还有20年得看老外的书，希望20年后中国人能在软件行业唱主角，出几个能和阿帕奇基金会相媲美的组织，这样下一两代就不用累死累活学英文了
有能力的同学，可以去找这本书的中译版第二版（可惜绝版了只能高价去问马云买，劳资是花了几倍的价，否则只能去看质量惨不忍睹的PDF扫描版），这个版本的翻译相对来说通顺多了
数据仓库工具箱（第3版）读后感第十篇
经典数仓架构书，翻译非常烂，影响到对于内容的理解。我需要找到第二版看一下，或者直接看英文原版，这个完全看不下去。。。。
我带着多值维度的问题去翻书：
如何处理多值维度？
如求职者的职业技能、病人的诊断和症状
一般来说，有两个选择： 位置设计和桥接表设计
位置设计：每个技能对应维度表的一列（one-hot编码）
我刚开始还以为我自己的理解能力问题，整个书非常拗口，语言极不通顺。
直到第14章医疗卫生为例，如P240
“然而，支付人分析工作需要的报销数据既代表利益又代表诅咒，” 诅咒。。。。。。这是人翻译的吗？
数据仓库工具箱（第3版）读后感第十一篇
1、有一年左右的数仓经验再读理解会更深刻；
2、有部分翻译确实烂，但是看了绝对有收获，别看翻译烂就不读。在所有中文计算机翻译书籍中，这本书的翻译水平占中等；
3、本书主旨是讲维度建模的理念，理论书籍，通过多个行业的建模案例说明维度建模各个理念和技术；
4、虽然书籍主要基于关系型数据库来将维度建模，但也适应与大数据领域的维度建模，相通的；
5、如果你是大数据平台开发或产品，读最后几章讲ETL系统的即可，前面理论不用读；
6、现在大数据数仓基本都是维度建模，建议数据仓库、ETL工程师、数据架构师等必读，不要绕过去，毕竟你看过牧师不看圣经的嘛。
数据仓库工具箱（第3版）读后感第十二篇
这本书的翻译实在不敢恭维，以下例举二个：
原文：
翻译：
原文：
翻译：
还是学好英文重要啊！
数据仓库工具箱（第3版）读后感第十三篇
日期维度要记那么多
维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖
4.3 事实表主要包含三种基本类型： 事务，周期快照，累积快照
5.3 缓慢变化维度SCD基础
几种类型，类型2 增加新行就是拉链表
维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖维度有时候要用代理键，而不是真实业务的值（自然键）。不要有依赖
数据仓库工具箱（第3版）读后感第十四篇
数据仓库的理论，首选当然是KimBall的《维度建模》。《维度建模》在CRM那章里提到几个术语：
分别是5种业务场景，有各自的成熟模型。
维度表结构中，我们一般会这么设计：
自增列作为主键，与相关事实表做关联, 这种主键没有任何语义，仅仅作为连接事实表的主外键关系，而且可以用来指代任何其他业务系统具有相同语义的实体，所以称之为代理键；
操作型表(OLTP)的主键，这类主键唯一确定了一个实体，作为维度表的唯一约束。这么做的好处，是将实体的任何一个变化都可以做为缓慢渐变维，存储下来。当更新实体属性的时候，如果需要保持原先实体的事实，那么就用SCD1，直接替换实体属性；如果需要对比实体属性更改前后的事实变化，就用SCD2，产生一条新的维度记录，之后的事实都关联到新维度记录的主键；如果实体新加了一个属性，就用SCD3, 存储之后的属性事实变化；
顾客队列组（复杂行为研究分组）：
我们是在即有顾客维度的情况下，还建立了“顾客队列组”。这个队列组的作用，用来保存符合一定条件的顾客，比如去年消费超过10万的顾客。根据需要我们会建立相当多的“顾客队列组”，将顾客维度做“水平分割”。这些顾客是通过事实表汇总计算出来的，目的是为了追踪他们近期的表现。
为了追踪这些特殊顾客近期的表现，我们生成了一个维度表记录他们的ID. 这些ID假如再和事实表Join, 就能抓取他们最新的事实指标。那么书中提到的通过建立“持久键”，与顾客维度表再Join, 又有什么用意呢！书中的每一章都从一个侧面介绍了维度建模的场景，而每个侧面都可以在你遇到的整个项目中被应用到。所以需要从其他章获取对“持久键”的阐述。
连续行为的步骤维度：
这个维度就是类似于在生产系统中出现的工艺路线维度了。每条工艺路线会有多种工艺，用step 1, step 2, step 3来标记要实现的工艺，监控每个产品经历了哪些工艺，各自的良品率；也可以用web访问页面的流程来解释：一个用户经历了打开页面，浏览页面，咨询产品信息，下单，付款，到等待收货，收获成功，直到订单完成。每一步都会有详细的操作日志，而每一步都会被一个步骤维度给打上标记，也就是生成一条记录。
准确时间范围问题：
这儿提到的时间范围，主要是开始和结束时间日期戳。举个互联网订单的例子，比如你下了一个订单，下单到付款，付款成功，装箱，发货，配送，完成收货，都是有时间间隔的。好比付款时间一旦确定之后，就等待收货了。这段时间，每个状态都会有开始时间和结束时间。比如装箱到发货，装箱开始时间，装箱结束时间，发货开始时间，发货结束时间。
书上建议：
装箱结束时间在装箱未结束时，不要打NULL标示，而是给一个相对虚拟的未来时间，比如9999/12/31. 这样的好处是不必考虑NULL匹配的问题；
装箱结束时间戳一旦打上，随即将这个时间，标记为发货开始时间。这么做的好处是在计算货品在仓库存储到离开仓库的总时间时，不需要麻烦的去计算每一状态的时间，再总计。
针对第一条我是赞成的。NULL在处理的时候，需要将其加个函数做转换，不如9999/12/31来的直接。而对这二条我不怎么赞成。有些时候，我们是需要计算装箱结束到发货开始的时间间隔，来监控企业仓储的作业效率的。装箱结束只是打包结束了，并不一定就发车送货了，除非这里是装车结束，倒也罢了。
客户满意度维度表：
这是非常有用的一种思维技术。一般我们在设计满意度的时候，会将各种满意度指标放在事实表一起存储，造成了一次性调查表。而将客户满意度指标放在一个维度表里面构建，在这个维度表上又可以做文章。
比如：
Satisfaction Key ( PK )
Delayed Arrival Indicator
Lost Luggage Indicator
Food Satifaction Indicator
Service Satisfaction Indicator
…
这些指标我们可以用文本标记，也可以用1，2，3，4，5衡量，这些指标加在一起，我们可以衍生出多种组合。从而给推算做出更精确的归纳。但是首先我们要维护这么一张表，各种可能性都需要预先存储好。
客户异常情况指标标注事实：
在任何的事件性事实表中，用异常维度表来标注事件发生了异常。围绕这个维度可以统计服务的质量是否稳定或者异常发生的频繁度。
从客户维度表联想：
1. 试图（View)是有自己特殊意义的。是对一组逻辑的封装，而不用去搜索整张表。起到的是语义层面封装的作用。在实际应用与基表之间，差了一张View，导致的结果是起不到缓冲作用。如果基表的一列改名字了，原先引用基表的逻辑都要更改，而假如基表有了一张试图（View），基表的列名的更改，只要在视图里面反映出来，也就是只要改试图定义就可以了。
2. 试图的另外一个作用是：无限制的模仿基表，作为数据仓库的维度表。比如客户维度表维护了一个“首次订单日”，“首次退货日”。这些由事实表统计出来的属性，变成了维度表的一个属性，一个可以被再次加工统计的属性。那么这些属性本身就是日期，可以归档到日期维度，但是从语义层面上，直接连接一个没有定义语义的维度表，显得缺乏可读性。所以试图就在这里起到一个语义定义的作用。
3. 维度建模的原则：以事实粒度为标准，展开维度表与事实表的设计。
4. 对维度建立新的计分属性或者标记属性。
标记属性：就是类似A,B,C,D,E,F,G一类的状态标识。比如客户评级
计分属性：就是类似用100，200，320等一系列不连续的数值来标识。比如薪资。
这两类属性可以存在一张事实表里面，当做是一个快照级别的事实表。还记得事实表分为哪几类嘛：
1）事务性事实表：（典型的销售表）日期，产品，地区，客户，数量；
2）快照性事实表：（典型的库存表）日期，产品，仓库，期初数量，期末数量；
3）累积性快照事实表：（典型的送货表）产品，客户，下单时间，出库时间，签收时间
由CRM的维度设计过程谈起，怎么来设计通用的业务维度：
1 选择事实
2 选择维度
3 选择粒度
4 连数据源
书上讲的过程，与我想的上面4点大同小异，分别是：选择建模的业务过程；确立粒度；选择维度；选择事实。
维度建模中，有一种特殊的操作，叫做上卷下钻。我认为下钻可以分两种：有维度层次的下钻，例如从一个大类往明细下钻；维度属性的下钻，例如从一个维度属性，下钻到另一个维度属性，但其实这两个维度属性是属于同一个维度的，比如商品品牌的销售汇总，下钻到商品尺寸的销售汇总，本质上值是对商品品牌和尺寸做了一次分组汇总查询，这种下钻我称之为drill through.
除了上卷下钻，还有一种维度特性，叫做缓慢渐变维(SCD:slowly changing dimension). 不同的书里面对SCD的分类不同，有的分得特别的细，有7，8种，甚至更多，有的则很粗犷，只是分类3种原型，其他的更细的分类只是当成衍生品而已。我也倾向于分得粗犷一些，便于理解，比如SCD1，SCD2, SCD3.
SCD1: 将维度属性的更新简单化，直接更新属性，没有其他辅助操作；
SCD2: 保留维度属性的变更历史或者标注当前正在使用的维度属性。这里涉及到两种操作，每一种操作都是从新建一行开始，保留变更历史需要加上时间戳，而标注当前正在使用的维度，则只需加一个isCurrent属性就可以了。当然我们可以将两者化而为一，加上开始和结束时间戳，并且加上isCurrent属性；
SCD3: 加属性。针对一个销售人员负责的销售区域变更或扩展的情况。这种情况，可以新加一行，在新行里加上另一个区域，并标注为最新维度成员；也可以用另一张表，新增一条新行，来记录维度成员的这个新属性。
零售业务-维度建模
促销维度：在零售中，如果我要同时使用多种促销手段，那么这种维度怎么设置？假如把促销手段都放在一个维度，那么在商品的销售事实表中，就无法灵活容纳多个促销手段。所以是不是要考虑加一个事实表，来记录商品销售的附加手段，这样多种促销手段就都可以放在一张表里体现。这张表着重记录的是订单号和订单商品及其商品促销手段。
在交付DW/BI项目过程中，有两张矩阵图需要完成，这两张矩阵图是全局性的布局，是对企业数据总线的规划，让维度共享到企业数据蓝图中，为每个部门提供数据统一保障了可能。
下面是针对零售行业的数据仓库数据总线矩阵以及相关利益方总线矩阵。针对不同行业应该绘制相应的两种总线矩阵，作为交付的一部分。作为数据总线应该考虑到企业的每个部门的需求，总结出整体性的维度，应用于每个部门，允许每个部门有自己独立的核算系统，但总线不能丢。最坏的情况是每个部门都有自己的数据术语，但是公司整体上缺乏 一致性统一。应当极力避免这类情况。
上面的矩阵图可以使用“亿图软件”来绘制。Excel其实也可以做到矩阵图展现。
除了常规使用的三类SCD(缓慢渐变维），第三版的《维度建模》还扩展了其他几类SCD：
1 微型维度 – Type 4：
这个翻译有些牵强。微型维度，是从一个大维度表中，分离出来的几个属性的集合。和SCD3不同的是，SCD3是在原来的维度表上加字段，加属性来表示容纳新的计量属性，而SCD4 – 微型维度，主要是拆分属性，将数量不超过5个，并且各个属性的离散值不超过10个单一值的属性，归纳到一个维度，用来简化原维度表的增长和变化。
比如原维度表的这些属性：年龄，购买频繁程度，收入级别。事实上，这些维度属性的值，是随时间一直在变化的，如果维度表很大，有百万级别，那么每一次更改，都会增加大量数据，给查询造成性能伤害。拆分出这些属性，并且将属性值做带状切割，比如: 年龄大于等于25，小于等于30；购买频繁程度为低；收入级别是大于等于8000，小于等于25000. 这样一切分，就比原来每更改一次就增加一条记录，要少很多记录，查询效率也能提高。
这里的微型维度，是事实表的组合键一部分。直接从微型维度来统计和查询事实，而不用关联维度表，再关联事实表，来做查询。
2 维度支架表 – Type 5
Type 5 = Type 4 + Type 1. 就是说由微型维度组成的Type 1，但外键是和维度表关联的。那么不禁要问，这么做的作用是什么呢，不就相当于只是把维度属性拆分出去而已嘛！和Type4将微型维度直接关联到事实表不同的就在于这里。微型维度一旦独立，直接与事实表关联，那么通过微型维度查询原维度表（从此维度表独立出来的微型维度），必须先关联事实表，再找维度成员。而当微型维度直接关联到原维度表，成为一个扩展属性时，不需要关联事实表，就能筛选出原维度成员。
3 囊括了SCD 1,2,3的 Type 6
当我们需要保留维度历史变化时，可以用到的建模方式是Typ2，Type 3. 这个情况比较复杂，参照下图：
行有效日期，行失效日期，当前行标识，都是 type 2的建模方式；而当前部门名称则是type 3的标准。type 1则比较隐晦，就在于当前部门名称的更新上。看第三个结果集，如果是type 2方式，应该是这样的结果：
Eduction → Strategy
Strategy → Critical Thinking
Critical Thing → Critical Thinking
那么现在全部更新成了 Critical Thinking, 说明是按照 type 1来做更新。
这么做的好处在于，如果按照部门来汇总数据，就不需要通过部门当前所有的产品，去和以往产品做关联，然后一路跟踪出产品历任部门。而是直接筛选出来产品历任部门。
4 双重外键的Type 7
在SCD 2 , 3的建模方式下，我们一般是使用当前维度成员的维度自然键，去关联维度表，找出维度成员的变化历史。这种方式本质上也可以接受。但是如果我们在事实表上加一个列，用来存储当前维度成员的自然键，那么整个历史数据就只需要一次关联即可。这种方式在大数据量维度表的情况下，更能提高查询效率。
另一种极限的方式，就是将上述的双重外键合二为一。但是被关联到2个同义的维度表上。一个维度表（A) 用来记录最新维度成员，另一个维度表(B)采用type 1的方式，将需要大量查询的维度属性放进来，将最新属性值更新到每一个维度成员，更新包括历史维度成员。这样的做法其实也是用空间换取了时间。A和B其实是同一个物理表的试图，当时用了不同的建模方式。维度表A是type 2模式，如果没有维度表B，在上千万维度上，通过关联来查询历史维度变化，效率不高。但是有了维度表B，同样一次直接关联查询就可以了。
左边的产品维度就是type 2类型，而右边的产品维度试图，则是从左边的产品维度衍生出来的一个试图，数量一样，只是给每个维度成员，不管是否已经被废弃（由于type 2的需要），都将当前维度成员属性附加在所有的维度成员上面，存在这个试图里面，当需要用到当前属性做过滤查询时，提高查询效率。
