Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1984627
  • 博文数量: 148
  • 博客积分: 7697
  • 博客等级: 少将
  • 技术积分: 3071
  • 用 户 组: 普通用户
  • 注册时间: 2006-03-10 23:04
个人简介

MiBDP,数据开发、项目团队、数据应用和产品在路上,金融保险、互联网网游、电商、新零售行业、大数据和AI在路上。对数仓、模型、ETL、数据产品应用了解。DTCC 2013演讲嘉宾,曾做过两款大获好评的数据产品平台。知识星球ID:35863277

文章分类
文章存档

2020年(1)

2019年(2)

2017年(2)

2016年(5)

2015年(1)

2014年(1)

2013年(6)

2012年(5)

2011年(24)

2010年(28)

2009年(1)

2008年(6)

2007年(30)

2006年(36)

分类: 数据库开发技术

2015-11-05 17:54:35

温习记录下
按重要性由大到小列举常见的错误:
10:在事实表中放置用于约束与分组操作的文字型属性。(不可避免时可设计到维度表中。)
9:在维度表中试图为了节省空间而限制使用详细的描述属性。(维度属性越详细越好。)
8:将体系与体系层次分解成多个维度。(重度雪花模型设计者,坏处是会增加事实表与维度表关联的复杂性,影响查询效率,多体系多层级维度是可做单一维度设计的。)
7:忽视跟踪维度变化的需要。(不考虑缓慢变化维的处理,可通过代理键来解决。)
6:通过增加更多的硬件来解决所有的查询性能问题。(优先考虑是否进行了软件层级的性能优化,包括不限于:正确合理的索引、分区分表甚至分库、集合运算、并行计算、分布式计算、数据聚合、业务逻辑拆分等。)
5:使用操作性或者智能关键字将维度表连接到事实表上。(排斥、不使用代理键。)
4:忽视事实表粒度的定义与使用。(糅合各种粒度的数据到事实表中。)
3:基于具体的报表来设计维度模型。(一般为了满足业务需要快速出报表,出现这种情况。但是还是得慢慢沉淀,不断迭代,演进出通用的维度模型。
2:希望用户以规范化的格式查询最底层的原子型数据。(这个活还是留给业务系统来干吧^_^)
1:舍弃在单独的事实表之间保持事实与维度的一致。(尽量达到不同事实表之间维度的高度一致,这是仓库总线结构的基础。)
阅读(4164) | 评论(0) | 转发(2) |
给主人留下些什么吧!~~